RozhovorCast6

Návrh API

Bill Venners: Zatímco pár lidí navrhoje programovací jazyky, mnohem více programátorů píše skutečné aplikace. Velké programy jsou často složeny z mnoha samostatných částí se svým API. Co považujete za důležité v tomto návrhu? Co dělá návrh dobrým? Kterých věcí si vážíte na API nebo na návrhu programu?

Guido van Rossum: To je opravdu tvrdá otázka. Jeden příklad za všechny. DOM API pro práci s XML považuji za velmi neuspokojivé. Původně bylo navrženo pro svět Javy. Nejsem si jist, zda ty samé problémy, které máme v Pythonové verzi, provází i verzi v Javě, ale mám pocit, že překlad DOM API do Pythonu je udělán způsobem velice blízkým Javě a tudíž je vcelku velice "nepythonní", což je samo o sobě slovo s nedefinovaným významem.

Bill Venners: Ale znáte-li ho z Javy, jste v Pythonu jako doma.

Guido van Rossum: To je přesně ten problém. Nemohu učit někoho jiného, kdo dělá pythonní rozhraní.

Nepythonní DOM API

Bill Venners: Co se vám nelíbí na DOM API?

Guido van Rossum: Je zde mnoho věcí, které vypadají jinak, než se chovají.

Bill Venners: Co myslíte tím "vypadají jinak, než se chovají"?

Guido van Rossum: V Pythonu může objekt mít atributy a metody. Metody můžete zavolat pomocí závorek a volitelného seznamu argumentů. Na atributy odkazujete pomocí tečky, např. foo.bar. V Pythonu existuje interní mechanismus, pomocí kterého můžete jednoduše implementovat něco, co vypadá jako atribut, ale je implementováno za použití páru funkcí pro získání a nastavení hodnoty. V posledních verzích Python je to trochu formalizované -- tyto atributy nazýváme vlastnostmi -- ale to samé můžete udělat i ve starších verzích Pythonu.

Když si čtu implementaci DOM, zjišťuji, že mnoho vlastností je implementováno za pomoci funkcí, které vykonají nějakou práci a vrátí nový, nějak vytvořený objekty při každém přístupu k vlastnosti. To ukazuje na špatné použití mechanismu vlastností. Pokud napíši program, který používá x.foo na dvou místech blízko sebe, pak předpokládám, že v obou místech používám tentýž objekt. Nepředpokládám, že získání foo poprvé způsobí dlouhé počítání a získání foo podruhé vyvolá totéž znovu. A navíc, nepředpokládám, že druhé x.foo mi vrátí odlišnou kopii dat. To je případ něčeho, co se mi na implementaci DOM API nelíbí.

Bill Venners: Jak chápu já, DOM byl definován právě jako jazykově nezávislé API portovatelné do jakéhokoli jazyka. Tato jazyková nezávislost ho tvoří nemotorným. V Javě se DOM používá ještě hůře, protože je "nejavovské". Proto byly vytvořeny další javovské DOM API, z nichž nejpopulárnější je asi JDOM.

Guido van Rossum: Lidé by měli udělat totéž pro DOM v Pythonu. Z pohledu Pythonu by bylo přirozenější reprezentovat XML strom jako vnořenou konstrukci z primitivních datových typů -- slovníků, seznamů a možná n-tic, stejně jako řetězců a čísel atd.

Veškerá abstrakce postavená nad primitivními datovými typy dělá DOM méně efektivním. Další vrstva abstrakce vám také ztěžuje intuitivní výkonostní charakterizování programu. Mým koníčkem je učit lidi vidět, že pokud napíší kod tímto způsobem, bude to rychlejší než pokud použijí jiný způsob. Myslím si, že je dobré vědět, které operace jsou pomalé a které rychlé. V Pythonu je to obtížné, poněvadž jediný rádek kódu může být vykonáván dlouhou dobu, protože volá knihovní funkci nebo dělá cokoli na milionu prvků datové struktury. Ale je dobré mít představu, které věci jsou rychlejší než jiné. Nevím, nakolik jste přijali obecné znalosti, ale dobrý Pythonní programátor má dobrou představu, které jazykové konstrukce jsou rychlé a které ne. Určitě víte, že lokální proměnné jsou rychlejší než globální, atributy objektů jsou rychlejší než volání metod apod.

Bill Venners: Hlásíte se k teorii, jež odkládá optimalizaci až do doby, kdy máte opravdový výkonnostní problém?

Guido van Rossum: Určitě, proto také můžete psát programy, které poběží delší dobu a nebudou vyžadovat razantnější zásah do kódu. Pokud mohu něco napsat na pěti nebo deseti řádcích, vždy budu preferovat pět řádků i když tyto řádky mohou běžet delší dobu. Ale pokud to mohu napsat na pěti řádcích dvěma různými způsoby, pak bych měl mýt nějakou představu nebo vodítko pro určení lepší operace.

Lidské faktory

Bill Venners: Mnoho Pythonních nadšenců mi řeklo, že pokud chtějí něco v Pythonu udělat, nejčastěji najdou nějakou snadno použitelnou knihovnu a napíší to na třech řádcích kódu. Jazyk Python sám mi přijde velmi přívětivý. Když jste navrhoval "lidské rozhraní" Pythonu, jakému účelu jste přizpůsoboval váš vlastní návrh?

Guido van Rossum: Návrháři jazyka ABC, praotce Pythonu, stavěli jazyk na zpětné vazbě od uživatelů. Sám jsem Python testoval velmi málo, ale byl jsem velmi otevřený vůči uživatelské komunitě.

Jsem emailový maniak, dostal jsem mnoho emailů jak od zkušených tak od začínajících uživatelů Pythonu. Jejich návrhy se uchovaly v mém mozku a na určitém místě se projevily lepším rozhodnutím ve prospěch čitelnějšího a srozumitelnějšího jazyka.

Je těžké formalizovat a říci: "Toto jsou má hlavní vodítka při návrhu jazyka a API." Mám mnoho zkušeností jako programátor. Programuji od mých 18 let v mnoha odlišných prostředích. Začínal jsem jako programátor skriptů na velkých mainframech, pokračoval jsem přes sdílené Unixové stroje, PC a desktopy. A pracoval jsem na mnoha různých typech projektů, od výzkumu po vývoj velkých aplikací.

Bill Venners: Máte tedy mnoho zkušeností, které vám usnadňují rozhodování kolem návrhu.

Guido van Rossum: Nic nedokáže vyvážit zkušenosti.

Bill Venners: Jste ale otevřený vůči zpětné vazbě, což vám pomáhá k lepšímu návrhu.

Guido van Rossum: Komunita uživatelů Pythonu provádí testování a vyhodnocování velkého množství prototypů, starších implementací a produktů třetích stran před jejich samotným začleněním do standardní knihovny. Nebojíme se přepsat celý systém. Díky jedné z výhod, která jde ruku v ruce s možností jednoduše upravovat kód programu, se nemusíme bát v budoucnu změnit naše rozhodnutí.

Změny v kódu mezi jednotlivými verzemi

Bill Venners: Někdy je nutné po uvolnění veřejné verze udělat vylepšení nebo změnu API. Programátoři však již většinou mají napsaný kód za použití tohoto původního API. Jakým způsobem provádíte nekompatibilní změny v kódu mezi verzemi?

Guido van Rossum: Nyní se velice snažíme neprovádět takové změny, které by mohly ovlivnit klientské programy, aniž by to nebylo nevyhnutelné. Pro zpětně nekompatibilní opravu chyby v návrhu se rozhodneme pouze za výjimečných okolností. Jak se rozrůstá komunita uživatelů Pythonu, stáváme se více konzevrativní vůči zásadním změnám, které mohou poškodit existující kód.

V raných stádiích jsem měnil drasticky syntaxi každých pár týdnů nebo měsíců. To se ale již nestává. Nyní necháváme věci pracovat postaru a přidáváme pouze nové, lepší vlastnosti, a snažíme se přesvědčit lidi, aby je začali používat. Začínáme je i případně varovat, pokud jejich program používá stará rozhraní; když někdo například používá zastaralou knihovnu pro regulérní výrazy, zobrazíme mu varování.

Rozhodovací proces Pythonu

Frank Sommers: Jak se rozhoduje, co bude součástí standardní knihovny? Pokud mám nápad a rozhodnu se napsat vlastní knihovnu, co rozhodne o jejím zařazení?

Guido van Rossum: Python je jazyk, ale je to také komunita. Komunita rozhoduje o mnoha věcech týkajících se vývoje jazyka, třeba o tom co přijde a co nepřijde do standardní knihovny. Akceptuji příspěvek od téměř kohokoli, pokud si myslím, že na něm je něco skvělého.

Bill Venners: Že na příspěvku je něco skvělého nebo na člověku, který ho zaslal?

Guido van Rossum: Na příspěvku. Lidi z komunity většinou neznám. Do roku 1994 jsem těžko poznal nějakou osobu kolem Python mimo Nizozemí tváří v tvář. Většina uživatelů byla z USA. Ne, vždy jsem se pokoušel hodnotit příspěvky podle obsahu a ne podle osobních vztahů.

V prvních dnech jsem adaptoval a realizoval nové nápady velmi rychle, komunita se rozrůstala a to znamenalo více a více přispěvatelů. Začal jsem si více vybírat. Mým prvním krokem byl vždy říci ne. Pokud dotyčný tuto odpověď nepřijal, začal jsem se ptát na jeho argumenty: "Proč si myslíte, že toto je užitečné nejen pro vás, ale i pro velký počet uživatelů Pythonu?"

Pokud napíšete jedno konkrétní řešení určitého problému, ale zároveň existuje mnoho různých způsobů, jak to udělat, pak, pokud to mohu ovlivnit, nechci toto řešení do standardní knihovny zařadit. Ale pokud je jen jedno obvyklé, téměř nejlepší řešení, zařadím ho do standardní knihovny mnohem radši.

Autoři obecných API jsou často neradi, pokud se jejich dítko stane součástí standardní knihovny, daleko radši jsou autoři API, které usnadňuje různé oblasti tvorby aplikací. Někdy si myslím, že jsem udělal chybu zahrnutím multimediální podpory v takové míře v jaké se nachází v dnešním Pythonu. Některá multimediální rozhraní jsou již zastaralá, osobně jsem ztratil o multimédia zájem a zároveň neexistují žádné relevantní informace o tom, kdo je v současnosti používá. Nemáme například podporu pro MP3, ale podporuje zastaralé audio soubory, které pravděpodobně již nikdo nepoužívá.

Na druhou starnu, například podpora pro Internetové protokoly je široce používaná. Máme také malou sbírku některých užitečných matematických algoritmů, které základní datové typy neimplementují. Pokud máte třeba seřazené pole, můžete provádět binární vyhledávání nebo binární vkládání do tohoto pole.

Při každé příležitosti se ozve velká skupina uživatelů z určitého oboru, mající pocit, že v dané oblasti to a to musíme okamžitě začít podporovat, protože určitě půjde o skvělou věc. A možná se v této aplikační oblasti stane Python opravdu dobrý, protože je v ní vyžadováno mnoho experimentování a prototypování. Velkým příkladem je XML.

Python podporuje XML velmi dobře, protože si kdysi silné lobby uživatelů řeklo, že XML se stane velkým formátem, a proto je Python tak dobrý jazyk pro práci s XML. Volali po podpoře XML ve standardní knihovně, protože se nemohli vázat na třetí strany. Proto jsem navrhl vytvořit oddělenou podporu XML pro Python. Ta prošla mnoha revizemi, testováními, vylepšeními a pak se teprve stala součástí standardní knihovny. A stále se rozrůstá. Jsou oblasti XML, které v Pythonu nejsou podporovány, ale najdete oddělené moduly, které se eventuálně jednou stanou součástí standardní knihovny a které tato zákoutí plně podporují.