changed:
-
Rozhovor s Guido van Rossumem, část 6.
======================================

Autor jazyka Python Guido van Rossum odpovídá na otázky Billa Vennera o
historii Pythonu, o vlivu jazyka ABC na vývoj Pythonu a o hlavních cílech
při vývoji Pythonu.

Originál rozhovoru je dostupný na http://www.artima.com/intv/guido.html .

:Author: `Jan Švec <mailto:honza(at)py(dot)cz>`_
:Date: 2005-10-05
:Copyright: Copyright (C) 2004-2005 `Jan Švec <mailto:honza(at)py(dot)cz>`_


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í.

Obsah
=====
 + RozhovorCast1 - Historie Pythonu
 + RozhovorCast2 - Cíle a návrh Pythonu
 + RozhovorCast3 - Rapidní vývoj v Pythonu
 + RozhovorCast4 - Závazky v programování
 + RozhovorCast5 - Statické vs. dynamické typování
 + RozhovorCast6 - Veřejné API jazyka Python