Python Jiří Znamenáček Py3k versus Python 2.x 2016-10-09

Python je řekl bych zcela typický příklad oběti vlastního úspěchu. Třeba takové unicodové řetězce se do dvojkové řady dostaly hodně velkou oklikou a ještě jenom proto, že „všichni je používají a není to vůbec špatný nápad, dát je tam pořádně ale pro verzi 2.0 už nestihneme“. A to se psal zrovna rok 2000 a nikdo ještě netušil, že se z Pythonu'u stane doslova a dopísmene hit.

Již v té době sílilo u BDFL a dalších klíčových vývojářů přesvědčení, že jazyk samotný – a systémová knihovna snad ještě víc – jim začíná přerůstat přes hlavu a že je třeba s tím něco udělat. A padlo rozhodnutí, kterého se v historii moc jiných jazyků/projektů neodvážilo (a když už, tak na něj většinou šeredně doplatily):

„Takhle už to dál nejde. Zkusíme to vzít (skoro) od základů a udělat to znovu a pořádně.“

Světlo světa tak spatřil jazyk Pyton 3.x, který je sice pořád ještě Python, ale podstatně elegantnější, chytřejší, nenucenější a vůbec mocnější. A mimo jiné také zpětně nekompatibilní.

Osobně uvedený krok hodnotím pozitivně – jakmile si na trojkové „vychytávky“ zvyknete, pracovat s dvojkou je pak už jenom utrpení. Ovšem mít na uvedený vývoj vliv, přivítal bych mnohem radikálnější rozchod s historií – ve trojkové řadě totiž i přes zpětnou nekompatibilitu zůstala hromada blbostí a zbytečností, které se také měly poroučet na smetiště dějin.

Navzdory původním tvrzením o prakticky nulové „backportaci“ novinek Python'u trojkového zpět do dvojkového toho za ty roky probublalo strašně moc.

Oficiální zdůvodnění snad jest, že to usnadňuje psát kód pro dvojkovou i trojkovou řadu současně. Praktický efekt je spíš ten, že zarytí odpůrci trojky mají čím dál tím více důvodů, proč na trojku vůbec nepřecházet. Pokud tedy nepracují v mezinárodním jazykovém prostředí, tam je dvojka se svojí dualitou „osmibitový řetězec VERSUS unicodový řetězec“ pekelná.

Takže se snadno může stát, že o nějaké věci tvrdím, že v Python'u dvojkovém nefunguje, zatímco v nějaké – dostatečně poslední – verzi řady 2.7 to tak vůbec už být nemusí.

Kdybych se chtěl se změnami v trojkové verzi Python'u vypořádat OPRAVDU velmi zkrátka, napsal bych asi:

Přitom na první věc se – řekl bych zcela zbytečně – nejvíc nadává, druhou všichni ignorují, než se poprvé spálí a pochopí, že to je ta zcela nejdůležitější věc, jaká se v celé historii Python'u stala, třetí je velmi příjemná změna v chování jazyka, na kterou se rychle a snadno zvyká (ve dvojkovém Python'u jsou iterátory také, ale musíte je chtít použít; ve trojkovém už jsou – většinou – jenom ony) a konečně čtvrtá vrátila do bažiny systémových modulů zase trochu řád.

http://python.org/doc/3.0.1/whatsnew/3.0.html
http://python.org/doc/3.0.1/tutorial/index.html

Začnu rovnou tím nejdůležitějším – způsobem uchovávání řetězců v paměti.

V trojkovém Python'u už to asi ani snažší být nemůže – napíšete-li někde typ řetězec (tedy cokoliv v nějaké z mnoha variant jednoduchých a dvojtých uvozovek), tak neřeknete-li v hlavičce (viz následující slajd) kdovíproč jinak, Python automaticky předpokládá, že jde o textová data v kódování UTF-8.

Zato v Python'u dvojkovém na vás čeká pěkný podraz – řetězce jsou totiž dvojího druhu:

Plus samozřejmě všechny jejich varianty s apostrofy, případně i trojtým opakováním.

Přitom platí, že tyhle dvojkové pseudořetězce se berou buď jako sekvence bajtů, pokud tomu tak konzument chce, nebo jako řetězce textové, pokud má někdo zrovna zájem, pak ale:

Každému je asi jasné, že je zaděláno na pořádný průšvih. Pokud tedy nepíšete všechno jen a pouze jenom jako ASCII…

V trojkovém Python'u je to (relativně) jednoduché, ten v základním nastavení trvá na UTF-8 skoro všude, tudíž i kódování zdrojových textů, a vaše smůla, když se třeba zrovna budete pokoušet psát zdrojový kód v kódování jiném.

V Python'u dvojkovém už v tuto chvíli asi nikoho nepřekvapí, že výchozím kódováním zdrojových souborů je aktuální/výchozí kódování celého systému! Což mimo jiné znamená:

PS: Hodně štěstí s přenosem zdrojáků, pokud jsou v nich „řetězce“ s neASCII-znaky. Nebo vůbec hodně štěstí s používáním knihoven, které napsal někdo, komu u"" nic neříká.

Oba druhy řetězců – osmibitové a unicodové – můžete ve dvojkovém Python'u mimo jiné třebas i skládat:

>>> "ahoj " + u"světe" u'ahoj světe'

Jenže daleko horší je, že funkce akceptující na vstupu „obyčejné“ řetězce "" si mohou s tímto vstupem dělat, co je zrovna napadne – někdy předpokládají, že jde o sekvenci bajtů, tedy v podstatě binární data, jindy se zase můžou k vaší hrůze rozhodnout, že jde o text ve výchozím kódování toho kterého systému!

Je jasné, že tohle je skutečně pořádný průšvih. Kterému se dá „vyhnout“ jedině tak, že se pohybujete pouze na úrovni ASCII (tedy vlastně sedmi bitů), kde jsou oba druhy řetězců v podstatě zaměnitelné.

Převádět takový kód, aby fungoval pod trojkovým Python'em, není vůbec žádný med, jak vás ostatně snadno přesvědčí třebas Mark Pilgrim ve svém Dive Into Python 3. Ovšem výsledek je miliónkrát lepší.

Další místo, kde se můžete kopnout do vlastní paty, ale tentokrát kupodivu spíše na straně Python'u 3.x, jsou názvy souborů na souborovém systému. A na vině jsou tentokráte tak trochu UNIXy, protože jsou prostě staré. (Což ovšem neznamená, že Python 3.x pro někoho věci oproti dvojkové řadě značně zkomplikoval.)

Celý problém spočívá v tom, že zatímco většina moderních operačních systémů názvy souborů ukládá v Unicodu (nebo alespoň pomocí jasně definovaného API), v Linuxu a jinde uvedené API akceptuje prakticky zcela libovolnou sekvenci prakticky jakýchkoli bajtů. Co to znamená pro trojkový Python, který se snaží seč může předstírat, že všechno je Unicode, je asi celkem jasné. Na druhou stranu uživatelé Windows a dokonce i Mac OS X jsou za vodou.

Jen tak na okraj – napíšete-li..

f = open('soubor.txt')

..dvojkový i trojkový Python se bohužel vzácně shodnou, že místo neuvedeného explicitního kódování zpracovávaného textového souboru se použije systémové :-( Opět hodně štěstí při „snadném“ sdílení zdrojových kódů mezi systémy s jiným výchozím kódováním…

Mimochodem tady už náprava snadná není: Zatímco ve trojkovém Python'u má funkce open() nepovinný parametr encoding, který trable s přenositelností vyřeší (alespoň než zakopnete o Unicode, který není tak úplně Unicode), v Python'u dvojkovém musíte na pomoc zavolat úplně jiný modul, konkrétně codecs.open(). „Happy coding!“

Ve trojkovém Python'u jsou jedna jediná celá čísla, a to „nafukovací“ (tedy dlouhá). Prostě jak velké číslo je potřeba, tak velké se zabere (pokud se vleze někam do paměti samozřejmě):

>>> 10**18 1000000000000000000 >>> 10**23 100000000000000000000000

V Python'u dvojkovém existují i celá čísla krátká a ta dlouhá se pak označují postfixem L (jde i l, ale to se snadno plete s jedničkou) a mají vlastní konstruktor long():

>>> sys.maxint 9223372036854775807 >>> 10**18 1000000000000000000 >>> 10**23 100000000000000000000000L

Práce s krátkými je celkem pochopitelně systémově méně náročná, ale kdo na to má pořád dávat pozor, že.

Ostatně kdo chce psát v čistém Python'u extrémně rychlé programy, asi si vybral špatný jazyk ^_~

Ve trojkovém Python'u dělení operátorem / pro celá čísla vrací, co by člověk čekal, a když chceme dělit celočíselně, použijeme operátor //. Tedy žádné překvapení na nás nečeká:

>>> 1 / 2 0.5 >>> 1 // 2 0 >>> 1.0 // 2 0.0

To v Python'u dvojkovém se asi nebudete stačit divit:

>>> 1 / 2 0 >>> 1.0 / 2 0.5

Nejvtipnější (nebo nejsmutnější?) na tom je, že operátor // je tam také a chová se očekávaně:

>>> 1 // 2 0 >>> 1.0 // 2 0.0

Když už jsme u té konzistence – v trojce všechno krásně sedí..

>>> hex(65) '0x41' >>> oct(65) '0o101' >>> bin(65) '0b1000001'

..ale běda vám ve dvojce!

>>> hex(65) '0x41' >>> oct(65) '0101' >>> bin(65) '0b1000001'

No kdo se v tom má vyznat?

Ve trojkovém Python'u je rozsah prostě rozsahem..

>>> range(10) range(0, 10)

..a dokud po něm nezačnete iterovat, tak se nic víc nedozvíte.

Ve dvojkovém Python'u je rozsah na druhou stranu obyčejným seznamem..

>>> range(10) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

..po kterém se ovšem z hlediska prvků iteruje zdánlivě stejným způsobem. Rozdíl spočívá v tom, že všechny ty prvky zabírají místo v paměti. Chcete-li ve dojkovém Python'u stejné iterátorové chování jako ve trojce, musíte použít konstruktor xrange().

Podobně byly změněny i slovníky – ve trojce se po nich iteruje..

>>> xs = {1: 'a', 2: 'b', 3: 'c'} >>> xs.keys() dict_keys([1, 2, 3]) >>> xs.values() dict_values(['a', 'b', 'c']) >>> xs.items() dict_items([(1, 'a'), (2, 'b'), (3, 'c')])

..zatímco ve dvojce dostaneme seznamy:

>>> xs = {1: 'a', 2: 'b', 3: 'c'} >>> xs.keys() [1, 2, 3] >>> xs.values() ['a', 'b', 'c'] >>> xs.items() [(1, 'a'), (2, 'b'), (3, 'c')]

Pokud tedy nepoužijete příslušné iterátorové varianty xs.iterkeys(), xs.itervalues() a xs.iteritems().

Nepřekvapivě stejnou iterátorovou změnou prošla do trojky i funkce zip:

>>> zip('abc', 'abcd') <zip object at 0x7f7c86af0c88>

Ve dvojkovém Python'u dostanete seznam:

>>> zip('abc', 'abcd') [('a', 'a'), ('b', 'b'), ('c', 'c')]

A zase – z hlediska iterace po prvcích objektu je výsledek stejný, ale prakticky ani filozoficky se vůbec nejedná o totéž. Iterátorovou variantu nepřekvapivě k dispozici máme, ale pěkně schovanou jako itertools.izip().

Asi nikoho už nepřekvapí, že funkce map je ve trojkovém Python'u iterátor..

>>> map(lambda x,y: x+y, 'abc', 'abcd') <map object at 0x7f7c86af2400>

..zatímco ve dvojkovém Python'u dostaneme opět seznam:

>>> map(lambda x,y: x+y, 'abc', 'abc') ['aa', 'bb', 'cc'] A to ještě podle verze buď dokáže nebo nedokáže zpracovat nestejně dlouhé vstupy.

A zase – je k dispozici i iterátorová varianta itertools.imap().

A kdo si myslel, že funkce filter zůstala „ušetřena“ ^_~, samozřejmě se mýlil:

>>> filter(lambda x: ord(x) > 91, 'AbCd') <filter object at 0x7f7c86af2438>

Ve dvojkovém Python'u obdržíme rovnou výsledek:

>>> filter(lambda x: ord(x) > 91, 'AbCd') 'bd'

Pokud nepoužijete iterátorovou variantu itertools.ifilter().

Když už jsme u iterátorů – další prvek sekvence se v trojkovém Python'u vyvolává pomocí vestavěné funkce next(), která nepřekvapivě volá magickou metodu __next__() objektu iterátoru:

>>> xs = 'ahoj' >>> i = xs.__iter__() # ve skutečnosti by se volalo „iter(xs)“ >>> i.__next__() # ve skutečnosti by se volalo „next(i)“ 'a'

Ve dvojkovém Python'u se metoda iterátoru jmenovala pro zmatení nepřítele naprosto nemagicky Iterátor.next(), i když konstruktor iterátoru byl očekávaně magicky Iterátor.__iter__():

>>> xs = 'ahoj' >>> i = xs.__iter__() >>> i.next() 'a'

Zatímco v Python'u trojkovém můžete generovat seznamy, množiny i slovníky..

>>> [x for x in "abeceda"] ['a', 'b', 'e', 'c', 'e', 'd', 'a'] >>> {x for x in "abeceda"} {'c', 'e', 'a', 'b', 'd'} >>> {i:x for i,x in enumerate("abeceda")} {0: 'a', 1: 'b', 2: 'e', 3: 'c', 4: 'e', 5: 'd', 6: 'a'}

..ve dvojkovém jste omezeni pouze na seznamy:

>>> [x for x in "abeceda"] ['a', 'b', 'e', 'c', 'e', 'd', 'a'] A jako vždy – od nějaké dva-sedmičkové verze už to není pravda a jsou tam i ty zbylé dvě.

Test nerovnosti dvou hodnot je ve trojkovém Python'u zapisován operátorem !=..

>>> 2 != 3 True

..zatímco v Python'u dvojkovém lze z historických důvodů použít ještě i operátor <>:

>>> 2 <> 3 True >>> 2 != 3 True

Při porovnávání hodnot provádí Python 2.x implicitní konverzi typů..

>>> 2 < '1' True

..nebo dokonce vyloženě páchá magii:

>>> len < len False

Dává vám to smysl? Asi moc ne, že. Tudíž není moc divu, že..

..ve trojce už nic takového není:

>>> 2 < '1' Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unorderable types: int() < str() >>> len < len Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unorderable types: builtin_function_or_method() < builtin_function_or_method() Čimž samozřejmě netvrdím, že vaše objekty (či dokonce funkce) se porovnávat nedají, protože dají, když budete chtít.

Trojkový Python zavedl – jako doplněk k základnímu lexikografickému způsobu – pro řazení objektů velmi mocný parametr key:

>>> xs = [ ('Láďa', 2), ('Jana', 1), ('Karel', 3) ] >>> sorted(xs) [('Jana', 1), ('Karel', 3), ('Láďa', 2)] >>> sorted(xs, key=lambda x: x[1]) [('Jana', 1), ('Láďa', 2), ('Karel', 3)]

V Python'u dvojkovém je k dispozici „klasická“ varianta pomocí porovnávací funkce za parametrem cmp:

>>> xs = [ (u'Láďa', 2), ('Jana', 1), ('Karel', 3) ] >>> sorted(xs) [('Jana', 1), ('Karel', 3), (u'L\xe1\u010fa', 2)] >>> sorted(xs, cmp=lambda x,y: x[1] - y[1]) [('Jana', 1), (u'L\xe1\u010fa', 2), ('Karel', 3)] Byť v posledních verzích dva-sedmičkové řady funguje i key.

I ve trojkovém Python'u jde pořád udělat následující..

>>> True + True 2

..protože Boolean je jenom podtyp int. Na druhou stranu už nejdou aspoň pravdivostní identifikátory přepsat:

>>> True = 'ahoj' File "<stdin>", line 1 SyntaxError: can't assign to keyword

Ve dvojkovém Python'u to ovšem ještě klíčová slova nejsou:

>>> True + True 2 >>> True = 'ahoj' >>> True + True 'ahojahoj'

Následující vlastnost dvojkové řady je skutečný podraz par excellence:

>>> [x for x in range(5)] [0, 1, 2, 3, 4] >>> x 4

Co heršoft dělá pomocná proměnná z generátoru seznamu v globálním kontextu?!? Ano, já vím, u smyček for-in ta proměnná také vybublá ven, ale tam se to dá snad i skoro čekat (byť netvrdím, že je to očekávané chování) a rozhodně snáze na to zvyknout.

Ve trojkovém Python'u už je chování očekávané:

>>> [x for x in range(5)] [0, 1, 2, 3, 4] >>> x Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'x' is not defined

Je to pouze o jeden znak víc, ale všichni na tuto změnu nadávají – z printu se ve trojkovém Python'u stala místo dřívějšího příkazu funkce. Drobnějších změn za tím schovaných je více, ale ty nejviditelnější jsou asi:

3.x 2.x
print(x, end='') print x,
print("Chyba!", file=sys.stderr) print >>sys.stderr, "Chyba!"
print( (x, y) ) print (x, y)

Obecně je „trojkový“ print() konzistentnější a díky armádě pojmenovaných parametrů nakonec i mocnější. Nehledě na to že ho jako funkci můžete snadno úplně předefinovat, což s příkazem pochopitelně nešlo.

Zkuste uhodnout, co bude v proměnné xs, když následujícímu programu zadáte na vstupu řetězec os.getcwd():

import os xs = input('Vstup: ')

Ve trojkovém Python'u pěkně spořádaně zadaný řetězec 'os.getcwd()'.

>>> import os >>> xs = input('Vstup: ') Vstup: os.getcwd() >>> xs 'os.getcwd()'

Ovšem v Python'u dvojkovém to snad radši ani nechcete vědět:

>>> import os >>> xs = input('Vstup: ') Vstup: os.getcwd() >>> xs 'C:\\PROFILES\\pirat'

Ano, je to tak – dvojkový Python automaticky volá na vstup funkce input() extrémně nebezpečnou funkci eval()!!! Radši si ani nezkoušet představit, co všechno se tímhle dá způsobit… Vstup bez vyhodnocení vrací ve dvojkové řadě funkce raw_input(), která se chová obdobně jako trojkový input().

Zatímco v trojkovém Python'u se tisknutelná reprezentace objektů dostane zásadně pomocí funkce repr()..

>>> repr(int) "<class 'int'>"

..v Python'u dvojkovém je kromě ní k dispozici i varianta se zpětnými apostrofy `` (tzv. backticks):

>>> `int` "<type 'int'>" >>> repr(int) "<type 'int'>"

Ve trojkovém Python'u se objekt výjimky pro zpracování odchytává logickým a průhledným způsobem pomocí klíčového slova as:

try: ... except Výjimka as v: ...

Přitom chcete-li odchytit vícero výjimek ve stejné větvi, oddělíte je čárkami:

try: ... except Výjimka1, Výjimka2, ...: ...

Pro zmatení nepřítele používá Python dvojkový obyčejnou čárku, ačkoliv nejde o žádnou zjevnou dvojici, ovšem pro odchycení objektu výjimky:

try: ... except Výjimka, v: ...

Vícero typů výjimek najednou pak naprosto nelogicky bere pouze jako explicitně závorkami vyznačenou n-tici:

try: ... except (Výjimka1, Výjimka2, ...): ...

Podobného „napřímení“ doznalo i vyvolání/přeposlání výjimky pomocí raise s dodaným parametrem, které se ve dvojkovém Python'u dalo zapsat dvěma způsoby:

raise Výjimka, parametr ↔ raise Výjimka(parametr)

Dnes je možný již pouze druhý způsob:

raise Výjimka(parametr)

PS: S výjimkami je to tedy poněkud zamotanější, protože ve dvojce existuje i varianta s trojicí, kde posledním prvkem je traceback. Ten se ve trojce předává magickým parametrem __traceback__, což sice poněkud protáhlo kód, ale podle mého většinové použití výjimek se stalo výrazně čitelnějším. Pro podrobnosti viz PEP 3109.

Zatímco v trojkovém Python'u zavedete konkrétní metatřídu u třídy pomocí pojmenovaného parametru..

class MojeTřída(metaclass=M): ...

..ve dvojkovém to byl/je magický parametr v těle třídy:

class MojeTřída: __metaclass__ = M ...

Zavolat metodu rodičovské třídy je ve trojkovém Python'u naštěstí už směšně jednoduché..

class Školák(Člověk): def __init__(self, *args): super().__init__(args) ...

..protože v Python'u dvojkovém se musela funkce super() volat s explicitními parametry:

class Školák(Člověk): def __init__(self, *args): super(Školák, self).__init__(args) ...