===============================================================
Guido van Rossum:  Python in New York
                   Part I -- The Origins of Python
===============================================================
Google New York's Technical Speaker Series.
Guido van Rossum giving his Python presentation
at the New York Google office on Wednesday, February 22nd 2006.
http://video.google.com/videoplay?docid=-7758421725489622662
===============================================================

Část I -- Kořeny (původ) jazyka Python

Guido van Rossum přednáší v prostorách firmy Google ve středu 22. února 2006.

Zrození jazyka Python

  • Prosinec 1989,
  • během dvou volných týdnů volného času.
  • Nejdříve bylo vše v hlavě.
  • Fat Mac, překladač Ligthspeed C, 20 MB hard disk. (Můj současný mobil je výkonnější, než počítač, na kterém vše vznikalo. Mimochodem, na mém mobilu rovněž jede Python.)
  • První kód: generátor parseru. (Při prvních pokusech s parserem docházelo k tříbení syntaxe, protože ze začátku nebylo úplně jasné, jak by měla vypadat.)
  • Brzy vznikl první běžící program.

První fáze vývoje trvala asi rok (ve volném čase). Únor 1992 -- první zveřejněná verze (usenet) pod licencí podobnou MIT.

Některé cíle návrhu

  • Chování podobné shellu (interaktivní režim i skripty). Interaktivní režim není dotažen do té míry, ale některé projekty jako IPython tímto směrem jdou. Jsem dinosaurus, který je docela spokojený s používáním klasického Bourne Shell.
  • Architektura umožňující rozšiřování (vytváření nových typů). Měl jsem bolestné zkušenosti s předchozím jazykem, který se nedal rozšiřovat [ABC].
  • Být jedním z mnoha nástrojů, dobře s nimi spolupracovat (work well with others). Měl by to tohoto prostředí dobře zapadnout. Původně byl vyvíjen na unixové platformě, takže odpovídal unixové filosofii (vědomě i podvědomě).
  • Dodatečná funkcionalita musí být implementovatelná odděleně.
  • Vyhnout se syndromu "Not Invented Here" (volné půjčování myšlenek odjinud).
  • Musí to jít udělat jako "projekt pro jednoho člověka" (zkratky, "řezání zatáček"). V takové situaci se musíte rozhodnout, které části jsou natolik důležité, že je chcete psát sami. Ostatní věci se pak řeší používáním již hotových knihoven a tím, že umožníte psát některé věci jiným lidem.

Proč je objektově orientovaným? [05:50]

Koncem 80. a začátkem 90. let jsem nebyl velkým příznivcem OO jazyků. Věděl jsem o Smalltalku a C++ a opakovaně jsem si kladl otázku: "Co je vlastně tak zvláštního na objektově orientovaných jazycích?"

  • Jedním slovem: rozšiřitelnost. Nutnost objektově orientovaného návrhu přirozeně vyplynula z požadovaných vlastností jazyka z hlediska implementace.

  • Původní návrh byl objektově orientovaný uvnitř a počítal s používáním OO notace pro volání metod. Na druhou stranu nepodporoval uživatelsky definované třídy.

    Během návrhových prací se přirozeným způsobem prosadila dynamická typová kontrola (dynamic typing) a způsob implementace jazyka, který klade velmi silný důraz na dobu běhu (runtime orientation). [07:50]

  • Přístup k metodě byl zobecněn do podoby prostorů jmen (namespaces). [08:11] ... mít jeden prostor jmen, který by sjednocoval vše, co je viditelné na globální úrovni v modulu -- konstanty, proměnné, typy, třídy, funkce nebo dokonce další modul. Vše by bylo v jednom prostoru. Neměl by existovat syntaktický rozdíl mezi těmito prvky. Rozlišit se dají až podle použití.

  • Každý objekt představuje sám o sobě prostor jmen.

  • Modul je jen další objekt.

  • Vyhledávání jmen je přizpůsobitelné po prostorech jmen. [09:11] Nebyl definován standardní způsob zpřístupňování podle jmen. Prostě jste se objektu zeptali, zda může dát k dispozici objekt jménem XYZ. Tázaný mohl vrátit výjímku nebo vrátil objekt a následně jste mohli jste prohledávat zase jeho prostor jmen.

  • Uživatelsky definované třídy byly zavedeny během prvního roku vývoje, ale po dlouhou dobu zůstávaly "obyvateli druhé třídy" (až do zavedení nového stylu tříd v Pythonu 2.2).

    [09:17] Zajímavou historickou skutečností je to, že třídy v tom smyslu, že byste prostřednictvím syntaxe jazyka (příkazem class) zapsali definici nové třídy, původně v návrhu jazyka neexistovaly. Nepřišlo mi na mysl, že celá ta objektově orientovaná architektura je rovněž logickým základem toho, aby bylo i uživateli umožněno definovat své vlastní třídy. Přidání příkazu class navrhl kolega, který měl možná větší zkušenosti s C++ a dalšími jazyky. Původní myšlenka byla taková: pokud potřebujete nový typ, napíšete si kousek kódu v jazyce C a přilinkujete to k interpretu Pythonu. Ale lidi nechtějí psát kousky kódu v céčku, dokonce ani kvůli tomu, aby definovali nový typ.

Dobré věci z jazyka ABC [10:32]

ABC je předchůdcem Pythonu. S návrhem jazyka ABC nemám nic společného. Ovlivnil jsem jej možná z jedné desetiny procenta. Vznikal totiž na konci 70. a na začátku 80. let v hlavách vynikajících vědců na CWI v Holandsku. Poté co dokončili návrh jazyka a vytvořili velmi hrubý prototyp, rozhodli se najmout skupinu programátorů, kteří měli vytvořit korektní implementaci jazyka. Já jsem byl jedním z nich. Takže jsem asi 4 roky strávil prací s těmito lidmi. I když jsem neměl vliv na návrh jazyka, zkoušel jsem to. Kdykoliv mě napadla dobrá myšlenka, jak by se jazyk měl upravit nebo přidat nový rys, vždy mi laskavě a jasně vysvětlili, proč to není nutné a že uživatelé ABC by těmito rysy byli spíš více zatíženi, než aby jim v něčem pomohly.

[11:52] Svým způsobem jsem tento odpor k změnám v jazyce zdědil. Myslím si, že to je dobrý přístup, protože jazyk by se měl měnit mnohem pomaleji, než s ním spojené knihovny, runtime atd.

Mimochodem, cílová skupina uživatelů ABC měla být jiná, než je tomu u Pythonu. ABC bylo určeno pro inteligentní a bystré profesionály, kteří se ovšem nezabývají vývojem software. Měl to být jazyk pro vědce, knihovníky, chemiky a další, kteří používali počítače. Sem tam si chtěli napsat malý program, který by jim zjednodušil práci. Nebyl určen pro vývojáře, kteří by psali software používaný někým jiným.

[12:50] Otázka z publika: Byl Python vytvořen pro nějakou cílovou skupinu? Odpověď: Jazyk měl splňovat především mé vlastní požadavky. Chtěl jsem mít k dispozici implementaci jazyka, který by byl produktivnější než C a mocnější (více se podobající opravdovému programovacímu jazyku) než Bourne Shell. Cílová platforma se navíc příliš nepodobala Unixu. Takže Perl 3, který byl v té době k dispozici, nemohl být použit. A na základě své předchozí dlouhé zkušenosti s lidmi kolem ABC se mi nelíbila syntaxe Perl 3.

[13:35] (obsah slajdu, o jazyce ABC)

  • Interaktivní příkazový řádek >>> Ve skutečnosti bylo obtížné používat ABC v neinteraktivním režimu.
  • Pět mocných datových typů: seznam, tabulka, n-tice, číslo, text.
  • Ortogonalita jako důležitý princip. Schopnost vzít jakýkoliv objekt a použít pro něj známé operace.
  • Žádná omezení: hodnoty mohou být velké podle toho, jak velkou paměť máme k dispozici. (Skryj tyto implementační detaily před uživatelem. Tato omezení by neměl zavádět již programovací jazyk.)
  • Čísla vyjadřují matematické hodnoty, ne bitové vzorky.
  • Zabudován mocný aparát pro zpracování řetězců.
  • Nepoužívají se deklarace typů; proměnné se vytvářejí v okamžiku přiřazení. [16:00] Zajímavým přínosem ABC je také odvozování typů (inference). Nemusíte deklarovat typy proměnných, ale přesto se používá se statická typová kontrola, tj. v době překladu. Python má podobné vlastnosti, ale kontrola typů se neprovádí v době překladu, ale až za běhu.
  • Jednoduché řídicí konstrukce: IF, SELECT, WHILE, FOR

Nedobré věci na jazyce ABC [16:38]

Python v sobě odráží vše dobré, co se mi na ABC líbilo. Zvým způsobem odráží také vše, co se mi na ABC nelíbilo. Dá se říci, že v návrhu Pythonu jsem se snažil opravit vše, co se mi na ABC nelíbilo.

  • Monolitická implementace; těžko se přidávají nové věci.
  • Obtížná spolupráce se systémem souborů. Bylo například velmi obtížné otevřít soubor a něco z něho přečíst.
  • Používání odlišné programátorské terminologie (znovuobjevování). Používaly se pojmy jako "text", místo "řetězec", "howto" místo "procedura", "yield" místo "funkce" atd.
  • Používání aplostrofu (') v identifikátorech; klíčová slova se zapisují VELKÝMI PÍSMENY.
  • Seznam má podobu neuspořádané multimnožiny (bag); tabulky jsou seřazené. [slajd říká neuspořádaný seznam, GvR říká uspořádaný 17:57 ?]
  • Práce s malými řetězci je relativně pomalá. (Dobře implementované řetězce z hlediska asymptotické složitosti, ale velká konstanta.)
  • Přiřazení: PUT výraz IN proměnná.
  • Chybí uživatelské zpracování chyb: chyba vede k návratu na >>> vyzývací řádek.
  • Prostředí pro editaci je příliš těsně integrováno. (Jazyk ABC je stále dostupný, napsaný v C -- zkuste Google.)
  • Přitažlivý většinou pro lidi, kteří se k počítači moc nedostali. Nepodařilo se získat komunitu příznivců v tvrdém jádře unixového světa -- kvůli špatné integraci s OS.

Co jsem změnil [19:20]

  • Rozšiřitelnost se stala základním kamenem implementace.
  • Zabudovaná podpora práce se soubory; ostatní funkčnost operačního systému dostala podobu rozšíření. Zabudováno velmi dobré rozhraní pro různé funkce operačních systémů. [19:30] Jednou z částí byly například vstup/výstupní operace, jak je definuje norma jazyka C. Jde o operace dostupné všude, i když se implementace může lišit (přenositelnost). [19:42] Od začátku jsem myslel na to, že programátoři na různých platformách budou chtít psát svá rozšíření zpřístupňující vlastnosti specifického operačního systému. [20:00] To je přístup, který pythonovský přístup v základech odlišuje například od jazyka Java. Přístup Javy "zkompiluj jednou a spusť kdekoliv" vede k jakési sadě rysů představující největšího společného jmenovatele [tj. využívání jen těch rysů, které jsou dostupné na všech platformách].
  • Návrat k standardní programátorské terminologii.
  • Používání znaku podtržení v identifikátorech; klíčová slova se zapisují malými písmeny.
  • Seznam je uspořádaný, slovník je implementován jako vyhledávací tabulka (hash).
  • Optimalizace pro malé řetězce (memcpy je velmi rychlé).
  • Tradiční zápis přiřazení: proměnná = výraz
  • Přidány výjimky, try/except/finally (Modula 3)
  • Zahozeno integrované editační prostředí.
  • Přitažlivost pro unixový svět: imitace chování shellu, # pro komentáře, podpora #!, přístupk nízkoúrovňovým voláním unixového systému (ale také přenos na PC/Mac!)

Co dalšího jsem změnil [20:58]

Přidal jsem další dobré věci, které nepocházejí z jazyka ABC. A taky jsem přidal pár svých chyb.

  • Řada věci byla motivována snahou udržet projekt natolik jednoduchý, aby to zvládl jeden člověk.
  • Opuštěno odvozování typů (type inference). Místo toho zavedeno dynamické určování typů (dynamic typing).
  • Zahozeny "zjemňující" řídicí struktury.
  • Zahozena konstrukce SELECT ve prospěch if...elif...elif...else...
  • Rozlišeny číselné typy int, long a float.
  • Největší chyby:
    • 32bitový integer (předčasná optimalizace)
    • celočíselné dělení ořezává výsledek (bezmyšlenkovitá imitace chování z jazyka C)
    • o třídách a typech se uvažovalo odděleně (uživatelsky definované třídy byly zavedeny později)
    • výjimky v podobě řetězcových objektů (mechanismus výjimek je starší, než mechanismus uživatelsky definovaných tříd).

[23:20] Otázka: [k celočíselnému dělení, volná sumarizace velmi dlouhé otázky] ... dělení celých čísel matematicky sice vede k obecně racionálním výsledkům, ale na druhou stranu, při numerických výpočtech je řada algoritmů kvůli výkonnosti optimalizována právě na celočíselné dělení...

[24:50] Odpověď: Pokud skutečně chcete, aby bylo celočíselné dělení uzavřeno v oboru celých čísel, můžete [do budoucna] používat operátor "i // j" místo "i / J". Jde o speciální operátor, který ořízne výsledek. Pravděpodobně to není celá odpověď na danou otázku. Je to také otázka filosofického přístupu. Python se řídí filosofií, která dává přednost "praktickému" přístupu k řešení problémů před "teoretickým". Právě praktické problémy uživatelů vedly k rozhodnutí změnit výsledek celočíselného dělení na typ float (reálné číslo). Pokud to skutečně potřebujete, můžete si definovat vlastní číselný typ, který definuje (overload) vlastní chování operátoru dělení.

Další vlivy [25:58]

  • Lisp: first class funkce. Někteří si o Pythonu myslí, že jde o jakousi druhou reinkarnaci Lispu, což mi připadá zábavné, protože jsem Lisp nikdy pořádně neznal. Určitě jsem o něm neuvažoval při návrhu Pythonu...
  • Smalltalk: interpret bajtkódu. ... To už se spíše dá hovořit o ovlivnění Smalltalkem (interpret bajtkódu a různé implementační techniky).
  • Emacs: ukládání přeloženého bajtkódu do souboru. (Drobné ovlivnění lispem, který je vnitřním jazykem)
  • Algol-60, Algol-68, Pascal: applehood & mother pie. První jazyky, se kterými se GvR seznámil. Patří k nim i jazyk ABC, i když byl syntakticky velmi odlišný.
  • Modula-3: try/except, třída jako záznam, explicitní používání self. [27:04] Kompilátor zde neví o tom, že kompiluje třídu. Chová se, jako kdyby kompiloval funkce. Že jde o třídu se pozná jen z kontextu. První parametr, předávaný funkcím, má speciální význam odkazu na záznam objektu. Tento koncept je zcela převzat z Moduly-3.
  • UNIX: modularita; standardní interaktivní chování,#! (konstrukce z jazyka C). Převzata klíčová slova, řídicí struktury, zápis speciálních znaků v řetězcích [escape characters] a podobné věci, zápis literálů, identifikátorů, čísel, atd.
  • Icon: slices; mhohem později generátory [27:49] Osobně jej neznám, ale pracoval jsem s kolegy, kteří přenos některých vlastností tohoto jazyka zprostředkovali.
  • Perl: syntaxe regulárních výrazů
  • Tcl/Tk: Tkinter; více interpretů; sandboxing
  • Java: nové aplikační rozhraní pro vlákna, reformy v oblasti výjimek (nedávno). [28:10]

[28:15] Otázka: Odkud pochází odsazování. Odpověď: Odsazování je vypůjčeno z ABC, ale jde o starší myšlenku. Jde o přístup běžně používaný v polovině 70. let.

[28:50] Otázka: Proč nejsou regulární výrazy zabudovány přímo do jádra jazyka? Odpověď: Souvislost s ABC, který regulární výrazy nepoužíval (byl určen pro výuku začátečníků). Python původně regulární výrazy také nepodporoval z podobných důvodů. Dalším důvodem je to, že přidávání nových věcí do Pythonu formou modulů je v 9 z 10 případů jednodušší, než úpravy jádra jazyka. A protože přidání regulárních výrazů formou modulu bylo možné, neprováděly se změny přímo do jádra. Jediným kompromisem bylo zavedení nové formy zápisu řetězce [r'raw string'], u které interpret není tak agresivní při interpretaci backslash.

Další poznámky [slajd zobrazen v čase 28:23]

[30:45]

  • Proč používat explicitně self? Pochází z Modula-3.
    • self.foo: odlišuje instanční proměnnou [tj. složku objektu] od lokální proměnné
      • důležité pro překladač (potřebuje vědět, kde se má ukládat)
      • důležité pro čtenáře-člověka
    • def bar(self, arg):
      • dovoluje dívat se na funkci jako na metodu nebo naopak.
  • Odkud přišla introspekce?
    • '__dict__' tady bylo od začátku jako mechanismus pro zveřejnění implementace
  • Je Python multi-paradigmatický jazyk?
    • Stěží. Podporuje procedurální a OO programování, ale je slabý co se týká funkcionálního programování a jiných přístupů.

(Konec první části. Pokračování -- PrednaskaGvRPythonInNewYorkII)




subject:
  ( 112 subscribers )