Python Jiří Znamenáček Pythoní záludnosti 2014-10-24

Ač je Python vesměs velice pěkný jazyk a spousta jiných si od něj obzvláště v poslední době dokonce nápady vypůjčuje, stejně se neobejde bez slušné řádky menších či větších pastí (a několika vyložených podrazů k tomu).

Některá z těch největších překvapení číhají na nepřipraveného programátora naštěstí pouze ve starší dvojkové řadě jazyka, ale i těch ostatních je slušná řádka a přestože jsou často někde zdokumentovaná, dokážou napoprvé nepříjemně překvapit.

Za tuhle přednášku může Daniel Kolář, který mi poslal odkaz na Python Puzzlers, kde jsem chvílemi jenom tiše (a občas i méně tiše :-) zíral, čemu všemu se mi zatím podařilo v Python'u vyhnout ^_^ Ve výsledku jsem dospěl k závěru, že by se vyplatilo známé i méně známé podobné podrazy sepsat na jedno místo, abych spoustě lidí ušetřil hromadu šedin a pár rozbitých čel (od mlácení hlavou do stolu nebo zdi). Další použité zdroje: When Pythons Attack, Python 2.x gotcha's and landmines, Common Python Pitfalls, 10 Most Common Python Programming Problems, The Insider's Guide to Python Interviewing…

Na začátek jednu méně známou třešničku (podraz to rozhodně není, ale překvapení nejspíš ano):

>>> xs = 'ahoj' "světe" >>> xs 'ahojsvěte'

Python za sebou napsané řetězce totiž automaticky spojuje do jednoho výchozího.

PS: Slavný „trik“ s odiskejpováním konce řádku pomocí zpětného lomítka funguje v Python'u také:

Když přišel Python 3.x, zcela po právu se chlubil, že žádné míchání tabulátorů a mezer v jednom zdrojovém kódu se už nadále nebude trpět.

Jaké bylo mé překvapení, když jsem si na čerstvě nainstalovaném systému v editoru opožděně zapnul zobrazování bílých znaků a ke své naprosté hrůze jsem zjistil, že debagovaný kód, který Python 3.7 vesele vykonával, obsahuje různou směsici tabulátorů a dokonce i několik typů odsazení mezerami!!!

Stejný kód na notebooku vybaveném stařičkým Pythonem 3.4 spustit nešel…

Netřeba asi říkat, že uvedené „vylepšení“ parseru pokládám za velmi nešťastné :-(

Ještě jedna z podobného soudku:

import os; os.getcwd(); print(dir(os))

No tak, klid, nebrečte, já vím, že vám říkali, že v Python'u nic takového nejde, to zas přejde…

PS: Jo, mimochodem, za dvojtečkou také nemusí být vždycky odřádkování:

for i in range(5): print(i); print("Dobře, teď už brečet můžete…") Ano, skutečně oba printy patří do těla téže smyčky…

Zkuste zodpovědět otázku, v jakém kódování bude otevřen textový soubor následujícím příkazem:

f = open('soubor.txt')

Správná odpověď zní: „Pokud pouštíte skript na tom a tom operačním systému, tak asi nejspíš v tom a tom kódování, ale není to jisté.“

Ano, je to bohužel tak – Python nemá žádné pevně dané výchozí kódování pro práci s textovými soubory*. Pokud kódování neuvedete, použije se aktuální výchozí systémové. Takže pokud všechny své soubory nemáte jenom v ASCII, dost dobře vám můžou skripty přestat fungovat hned při přístím apgrejdu operačního systému…

* Ale bude mít, ve čtyřce, UTF-8. O verzi později, než mít měl… (Mimochodem trojku můžete spustit s parametrem python -X utf8, a pak se tak chová také…)

Poučení je jasné – při práci s textovými soubory zásadně uvádějte kódování!

Bohužel úplně stejná poznámka se týká i zdrojových kódů ve dvojkovém Python'u – když si nějaké kódování nevyberete a neuvedete ho na začátku souboru (na konci ukážu jak), použije se výchozí systémové. Hodně štěstí se sdílením zdrojáků s dalšími lidmi…

Trojkový Python se bohudík pochlapil, takže v něm když neuvedete žádné kódování, bude trvat na UTF-8 a vaše smůla, když to budete zkoušet psát v jiném.

Zde je univerzální řešení podobné jako u textových souborů – prostě si kódování vyberte a napište ho do hlavičky, například takto:

# encoding: utf-8

Python zkousne téměř libovolný popis, pokud v něm někde na začátku bude podřetězec coding a na konci identifikace příslušného kódování.

PS: Prokažte sobě i ostatním službu a pište všechno radši rovnou pěkně v Unicodu.

Na druhou stranu – ačkoli je Unicode geniální myšlenka a algoritmus UTF-8 pro jedno z jeho mnoha kódování jakbysmet, nebylo a není vyhodnocování souborů v tomto konkrétním kódování vždy bez problémů. Ty vesměs pramení z toho, že soubor zakódovaný podle UTF-8 může, ale nemusí mít svůj příslušný BOM EF BB BF.

Problém je zakukleně přítomen i v Python'u, protože:

Načtete-li soubor v kódování UTF-8 Signature (tedy s BOMem) jako utf-8, příslušné tři bajty BOMu ze začátku souboru probublají do řetězcových operací, ačkoli se při tisku budou zásadně tvářit jako prázdný řetězec!

Prakticky se to projeví například tak, že když se pokusíte začátek souboru porovnat s nějakým řetězcem, porovnání selže, přestože print() příslušné části bude tvrdit, že není důvod (protože se vytiskne přesně to, co byste čekali – totiž očekávaný řetězec, pěkně bez BOMu).

Snad z důvodů interoperace s jinými programy Python uvedený problém „vyřešil“ tak, že zavedl ještě jedno kódování utf-8-sig, které při čtení uvedené tři bajty na začátku odstraní* a při zápisu je tam naopak přidá. Tak tak, v jednoduchosti je síla… *povzdech*

* Ale pouze jednou, kdybyste náhodou někdy natrefili na šílený soubor s vícero BOMy na začátku. Zvlášť dřív to asi nebýval až tak takový problém.

Když už jsme u těch řetězců a kódování – ve dvojkovém Python'u vlastně nic takového jako textové řetězce ani neexistuje…

Dvojkový Python totiž u řetězců, které jsou označeny jenom uvozovkami, používá stejný princip jako u zdrojáků a souborů – interně je pokládá za obyčejné sekvence bajtů (tedy za osmibitové řetězce!) a jen pro vás je vyhodnocuje ve výchozím kódování aktuálního operačního systému. A samozřejmě všechny knihovny, které takovéhle „řetězce“ přebírají na vstupu, je také pokládají za obyčejné sekvence bajtů.

Teď už asi začínáte chápat, jaké průšvihy na vás mohou čekat při převodu kódu z dvojkové do trojkové řady, pokud v něm často takovéhle „řetězce“ někam předáváte…

Ve trojkovém Python'u jsou už naštěstí řetězce skutečné řetězce (a to unicodové). Ve dvojkovém Python'u takové řetězce získáte označením u"".

Kteréžto označení díky djangistům, kterým se blbě udržovala verze kódu pro obě řady, od verze 3.4 zase můžete použít. Ale v novém kódu jen pro trojkový python pro to není naprosto žádný důvod a jestli ho u někoho uvidím, tak budu tahat za uši!

Dejte si také pozor na otevírání souborů v „podivných“ cestách „wokenním“ způsobem se zpětnými lomítky, např.:

open('thedir\newfile.txt')

Za prvé je vůbec zbytečné zpětná lomítka používat, protože Python si většinu cest pohlídá na všech platformách správně i s klasickými dopřednými lomítky, a za druhé se tím právě vyhnete problémům ve chvíli, kdy kombinace zpětného lomítka a prvního znaku následující cesty „vyrobí“ zřejmě nezamýšlený řídicí znak (jako právě zde znak nové řádky \n).

Po každé písemce opravuji absolutní cesty ze studentských počítačů, abych mohl programy vůbec spustit. A to přesto, že neustále zdůrazňuji, že relativní cesty jsou mnohem lepší. Bohužel, není to tak úplně pravda – zkuste si kupříkladu následující kód s otevřením souboru (zde sama sebe) spustit ze dvou různých míst:

Pustíme-li program ze stejného adresáře, ve kterém je umístěný, je vše v pořádku a podle očekávání:

$ python pitfalls.2.py

Když ovšem zkusíte totéž s programem zavolaným v relativní cestě, máte problém:

$ python _files/pitfalls.2.py

A dokonce vám nepomůže ani zavolat program s absolutní cestou! Prostě jak není interpret spuštěn v místě umístění programu, relativní cesty v programu nebudou fungovat tak, jak byste – podle mě po právu – čekali. Taky vám to přijde divné? 0_o

Tohle přeci musí být někde zdokumentované? 0_o PS: A na stejný průšvih narazíte u importu modulů, pokud se pokusíte upravit sys.path za běhu programu spuštěného takto relativně vůči místu zavolání interpretru.

A ještě jednou k řetězcům, tentokráte k jejich formátování trojkovým způsobem:

>>> s = 'ahoj' >>> f'{s}' 'ahoj'

A teď si představte, že chcete formátovanou hodnotu vypsat zrovna ve složených závorkách. Tak je zkusme pro začátek zdvojit:

>>> f'{{s}}' '{s}'

Tedy zrovna tohle jsem opravdu nečekal, to spíš nějakou chybu… Hm, speciální funkce znaků v řetězcích se v Python'u přece ruší pomocí zpětného lomítka, že? Tak to zkusme:

>>> f'\{{s}\}' File "<stdin>", line 1 f'\{{s}\}' ^ SyntaxError: f-string: single '}' is not allowed Chybové hlášení se může lišit podle verze Python'u nebo při použití funkce format(), nicméně neprojde to nikdy. A kdybyste ho náhodou vzali vážně: >>> f'\{{s}}' '\\{s}'

No tak co opačně?

>>> f'{\{s\}}' File "<stdin>", line 1 f'{\{s\}}' ^ SyntaxError: f-string expression part cannot include a backslash

No dobře, takhle to teda zjevně nepůjde. Tak se zkusíme rozšoupnout a dáme tam ty složené závorky třikrát:

>>> f'{{{s}}}' '{ahoj}'

Bingo! Inu, to víte – v čitelnosti je přeci síla…

A při použití funkce format() s automatickým doplňováním parametrů je výsledek obzvláště hyenoidní: >>> '{{{}}}'.format(s) '{ahoj}'

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'

Ve většině spořádaných jazyků se dá proměnná cyklu zavést jako interní pouze pro daný cyklus. Python však cyklem nový kontext neotevírá a navíc všechny další případné proměnné stejně musíte zavést dopředu, takže v ní nepřekvapivě zůstane viset poslední hodnota ze smyčky:

>>> for x in range(5): ... print(x) ... 0 1 2 3 4 >>> print(x) 4

PS: Někdy se to řeší explicitním smazáním proměnných cyklu pomocí příkazu del ihned po ukončení smyčky.

Zatímco předchozí podivnost je možná nešťastnou (byť někdy hodící se) vlastností Python'u, 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?!?

Opět bohudík ve trojkovém Python'u už na dotaz o hodnotě proměnné x dostanete očekávanou výjimku NameError: name 'x' is not defined. Další z mnoha důvodů, proč používat trojkovou řadu ^_~

Bohužel zavedení operátoru := (aka walrus čili „mrož“) v Python'u 3.8 do předchozího opět hodilo vidle:

>>> [z for x in 'ahoj' if (z := ord(x)) % 2 == 0] [104, 106] >>> x Traceback (most recent call last): File "<pyshell#3>", line 1, in <module> x NameError: name 'x' is not defined >>> z 106

Asi nám není souzeno, aby Python někdy dokonvergoval do stavu bez podrazů…

Zatímco v následujícím kódu vypadá pokus o odstranění všech výskytů písmene a v pořádku..

>>> xs = list('abrakadabra') >>> for x in xs: ... if x == 'a': ... xs.remove('a') ... >>> xs ['b', 'r', 'k', 'd', 'b', 'r']

..hned ten další ukáže, že to je jen náhoda:

>>> xs = list('-----ahojte') >>> for x in xs: ... if x == '-': ... xs.remove('-') ... >>> xs ['-', '-', 'a', 'h', 'o', 'j', 't', 'e']

Jako mnozí jiní totiž Python připraví iterátor smyčky „dopředu“ a následně už jeho provázání s aktuální realitou nekontroluje.

Což nám názorně předvede rozklad smyčky pomocí iterátoru: >>> xs = list('abrakadabra') >>> it = iter(xs) # První znak je spořádaně první „a“: >>> next(it) 'a' >>> xs.remove('a') # Jenomže jeho odstraněním jsme seznam zkrátili a další krok tak # přeskočí „b“! >>> next(it) 'r' >>> next(it) 'a' >>> xs.remove('a') # Tady zase přeskočíme „k“: >>> next(it) 'a' >>> xs.remove('a') # A tady „d“: >>> next(it) 'a' >>> xs.remove('a') # A ještě i to druhé „b“: >>> next(it) 'r' >>> next(it) 'a' >>> xs.remove('a') >>> next(it) Traceback (most recent call last): File "<stdin>", line 1, in <module> StopIteration >>>

Když už jsme u těch iterací – v Python'u nejde napsat:

while PROMĚNNÁ = VÝRAZ: …

Je to úmyslné rozhodnutí již z počátků Python'u, aby se zamezilo chybám, kdy někdo nechtěl přiřadit ale porovnat. (Proč tedy hernajs radši nevymysleli jiné přiřazení nebo porovnání?)

Podle kontextu je doporučovaným pythoním řešením buď smyčka for-in (při iteraci nad souborem třeba) nebo použití idiomu while True: while True: PROMĚNNÁ = VÝRAZ if not PROMĚNNÁ: break …

Ale nemusíte smutnit – v létě roku 2018 Guido van Rossum prosadil přes všeobecnou nevoli PEP 572 (možná nepřekvapivě jeho poslední krok v roli BDFL, jíž se následně vzdal), který umožňuje použití nového operátoru := mimo jiné v následujícím kontextu:

while chunk := file.read(8192): process(chunk)

V které verzi Python'u se ale objeví (jestli vůbec nějaké), toť ovšem otázka.

Tak nakonec to byla verze 3.8.

Další zdokumentovaná, někdy se dokonce hodící, ale většinou překážející a přinejmenším na pár prvních setkání pěkně zákeřná vlastnost Python'u:

>>> def fn(x, xs=[]): ... xs.append(x) ... print(xs) ... >>> fn(1) [1] >>> fn(2) [1, 2]

WTF?!? Výchozí hodnoty parametrů jsou totiž vyhodnoceny pouze při prvním volání funkce bez explicitního uvedení příslušných parametrů a od té chvíle dál už se s nimi pracuje jako se známými. A pochopitelně je to pravda i u metod tříd, takže paseka na entou…

Dokud tedy budete funkci volat s oběma parametry, vše se bude tvářit přesně tak, jak by člověk čekal. Teprve ve chvíli, kdy poprvé zavoláte funkci bez druhého parametru xs, bude – poprvé a naposled – vyhodnocena jeho výchozí hodnota. Týká se to samozřejmě pouze parametrů, které jsou proměnnými typy – ty neproměnné jsou z principu zavedeny pokaždé znovu. Pokud je ovšem nezavedete jako na dalším slajdu…

PS: Někdy se to může hodit – často volaná funkce si takto může třebas do slovníku (který tím pádem nemusí být globální) hešovat vstupy a spočítané výstupy a pekelně se tím zrychlit. Ale často je to ke vzteku a budete to obcházet pomocí:

def f(x, xs=None): if xs is None: xs = [] xs.append(x) return xs

Překvapením ovšem ještě není konec – stačí zavést výchozí hodnotu parametru odkazem na globální proměnnou neproměnného datového typu a hned je všechno také úplně jinak, než by člověk čekal:

>>> x = 3 ... ... def fn(y=x): ... print(y) # Tady ještě dobrý: >>> fn(5) 5 >>> fn() 3 # Ale co je tohle? 0_o >>> x = 2 >>> fn() 3 >>> fn(4) 4 >>> fn() 3

WTF2?!? Jo jo, je to tak – Python totiž hlavičku funkce zpracuje pouze při jejím prvním čtení, a v tu chvíli měla proměnná x hodnotu 3, která jí tak „poněkud“ neintuitivně zůstane i nadále…

Něco podobného se ale děje i s lokálními objekty uvnitř těl funkcí. Zatímco následující kód v pohodě projde..

>>> xs = 'Ahoj!' >>> def fn(): ... print(xs) ... >>> fn() Ahoj!

..tento kód už beznadějně selže:

>>> xs = 'Ahoj!' >>> def fn(): ... print(xs) ... xs = "Nazdar!" ... >>> fn() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 2, in fn UnboundLocalError: local variable 'xs' referenced before assignment

Proč? Python totiž při prvotním překladu kódu (tedy ve fázi, kdy by se při importu vyráběly soubory *.pyc) v těle funkce zjistí, že do proměnné xs bude přiřazeno (zde hodnota Nazdar!), a tudíž ji bude pokládat za lokální pro danou funkci. Jenže když se pak příslušnou funkci pokusí vykonat, najednou po něm budete chtít, aby vytiskl hodnotu proměnné dříve, než byla zavedena.

Naproti tomu v prvním příkladě se do xs ve funkci nic nepřiřazuje a Python proto poslušně hledá v nadřazeném kontextu proměnnou stejného jména (kterou najde, a to s hodnotou Ahoj!).

PS: Ještě zákeřnější varianta předchozího, protože vše je utopeno a schováno v rámci jediné řádky:

>>> x = 3 >>> def fn(): ... x += 2 ... >>> fn() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 2, in fn UnboundLocalError: local variable 'x' referenced before assignment

Následuje na první pohled zcela neprůhledná chuťovka:

>>> def násobky(): ... return [lambda x : i * x for i in range(5)] ... >>> for násobek in násobky(): ... print(násobek(2)) ... 8 8 8 8 8

Náprava je jednoduchá (tedy pokud nepotřebujete nutně vrátit právě seznam) – stačí místo generované struktury vrátit přímo příslušný generátor:

>>> def násobky(): ... return (lambda x : i * x for i in range(5)) ... >>> for násobek in násobky(): ... print(násobek(2)) ... 0 2 4 6 8

Rozdíl mezi oběma příklady je v tom, že v případě generátoru je příslušná vytvořující funkce volána postupně po svých jednotlivých krocích, zatímco vrácení seznamu ji donutí nejdříve celou proběhnout. A protože Python používá při vyhledávání hodnot proměnných v uzávěrech „zpožděné přiřazení“ (late binding), při kterém jsou hodnoty hledány v okolním kontextu až ve chvíli zavolání funkce (nebo jinak: proměnné v uzávěru jsou vázány přeze jméno, nikoli hodnotu), dostane každý prvek seznamu poslední hodnotu proměnné i, tedy 4. Tak trochu symbolicky:

# a) seznam [lambda x: i*x, lambda x: i*x, lambda x: i*x, lambda x: i*x, lambda x: i*x, ] # b) generátor yield (lambda x: i*x)

PS: Pokud byste nutně potřebovali vrátit nikoli generátor ale skutečně právě a jenom seznam, dá se to s pomocí výchozích parametrů funkcí také zařídit, ale už to asi není na první pohled tak průhledné:

>>> def násobky(): ... return [lambda x, i=i : i * x for i in range(5)] >>> for násobek in násobky(): ... print(násobek(2)) 0 2 4 6 8

S rozpisem vrácené struktury už je to jasnější:

# c) seznam s „i“ jako výchozím parametrem [lambda x, i=0: i*x, lambda x, i=1: i*x, lambda x, i=2: i*x, lambda x, i=3: i*x, lambda x, i=4: i*x, ]

Mimochodem – jaké z toho všeho plyne poučení? Generátorová notace rulez! ^_~

PS: Tohle celé se dá zjednodušit v odpověď na otázku, co má vrátit druhý print() v následujícím kódu:

i = 1 def f(): return i print(f()) # 1 i = 2 print(f()) # ?

Python patří k jazykům, které – asi nepřekvapivě – vrátí 2. Kdyby vracel 1, kód ze začátku by se choval možná očekávaněji, ale na mnoha jiných místech zase vůbec. Zlaté funkcionální programovací jazyky, ve kterých tenhle problém ani nemůže vzniknout!

Podobné a na první pohled zcela nepochopitelné překvapení nás čeká i na zcela nečekaném místě – u metody fromkeys() slovníku:

>>> xs = {}.fromkeys('abc', []) >>> xs {'a': [], 'b': [], 'c': []} >>> xs['a'].append(1) ... xs['b'].append(2) ... xs['c'].append(3) >>> xs {'a': [1, 2, 3], 'b': [1, 2, 3], 'c': [1, 2, 3]}

Metoda fromkeys() se totiž (převážně z historických důvodů) v podstatě chová takto..

prázdný_seznam = [] xs = {}.fromkeys('', prázdný_seznam) A v dokumentaci je to výslovně uvedené: All of the values refer to just a single instance, so it generally doesn’t make sense for value to be a mutable object.

..takže všechno jsou to reference na stejný proměnný objekt 0_o Napravit se to tudíž musí buď generátorovou notací (opět :-)..

>>> xs = {x:[] for x in 'abc'} >>> xs {'a': [], 'b': [], 'c': []} >>> xs['a'].append(1) ... xs['b'].append(2) ... xs['c'].append(3) >>> xs {'a': [1], 'b': [2], 'c': [3]}

..nebo ručním zavedením každého prvku slovníku nezávisle na ostatních (pro malý počet klíčů) nebo též použitím defaultdict, má-li to v daném případě smysl.

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()'. Ovšem v Python'u dvojkovém to snad radši ani nechcete vědět – '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() a není se vůbec čemu divit, že v řadě trojkové už je jenom tahle varianta (a s krátkým jménem samozřejmě). Ve dvojkové řadě ve vlastním zájmu snad po uživatelích vstup radši ani vůbec nechtějte.

Ale kdeže! Stačí si zkusit tohle:

>>> xs = ([1],) >>> xs[0] += [2,3] Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'tuple' object does not support item assignment >>> xs ([1, 2, 3],)

Následující varianta dokonce ani nevyplivne výjimku:

>>> xs = ([1],) >>> xs[0].extend([2,3]) >>> xs ([1, 2, 3],)
A jak se můžete pomocí funkce id() snadno přesvědčit, v obou případech se i po změně jedná stále o stejný objekt…

PS: Do třetice švandy kopec – následující varianta zakřičí výjimku a nic neudělá, to je pane konzistence…

>>> xs = ([1],) >>> xs[0] = xs[0] + [2,3] Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'tuple' object does not support item assignment >>> xs ([1],)

PPS: Částečné zdůvodnění pro toto podivné chování je k nalezení v Python FAQ.

Když už jsme u těch n-tic. Tohle je vlastně nakonec celkem pochopitelné, ale když to uvidíte poprvé, asi budete chvilku zmateně zírat:

# Tak moment – co to je? >>> x, = 'a' >>> x 'a' # Aha, jednoprvkový iterovatelný objekt: >>> x, = ['abc'] >>> x 'abc'

S předchozí podivností proměnných n-tic úzce souvisí rozdíl mezi přiřazením pomocí operátoru += a jeho nezkrácenou variantou.

# Vytvořme seznam ⇒ obsadí si určité místo v paměti: >>> xs = [1,2,3] >>> id(xs) 140322828036936 # Rozšiřme ho pomocí „+=“ ⇒ a je to stále stejný objekt: >>> xs += [4] >>> xs [1, 2, 3, 4] >>> id(xs) 140322828036936 # Rozšiřme ho klasicky ⇒ a vyrobíme nový objekt: >>> xs = xs + [5] >>> xs [1, 2, 3, 4, 5] >>> id(xs) 140322827952904

Zatímco klasické = + (implementované jako magická metoda __add__, resp. __radd__) nepřekvapivě nejdříve vyhodnotí pravou stranu výrazu a výsledek přiřadí do nově vytvořeného objektu, byť stejného jména, zkrácené += (implementované jako magická metoda __iadd__) provádí výměnu v rámci původního objektu (in-place).

Dá se očekávat, že změna objektu pomocí += bude ve většině případů rychlejší – zatímco klasická varianta musí místo pro nový objekt alokovat vždy, zkrácená to bude muset udělat jenom tehdy, když přiřazovaná data přesáhnou místo předalokované proměnnému objektu.

Aby švandě nebyl konec, += se navíc chová mnohem více jako metoda na příslušném typu (dokáže zkonvertovat svůj vstup na požadovaný tvar) než operátor:

Především pomocí += se dá složit téměř cokoliv, byť trochu překvapivě prvek po prvku:

>>> xs = [1, 2, 3, 4, 5] >>> xs += {6, 7, 8, 9} >>> xs [1, 2, 3, 4, 5, 8, 9, 6, 7]

„Přičítaný“ objekt tedy není přidán jako poslední prvek seznamu, ale je proiterován prvek po prvku a takto také postupně popřidáván.

Ovšem na druhou stranu výše uvedený trik (pochopitelně) nefunguje pro = +:

>>> xs = [1, 2, 3, 4, 5] >>> xs = xs + {6, 7, 8, 9} Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: can only concatenate list (not "set") to list

Operátor prostě implicitní konverze typů neprovádí, zatímco metody objektů (a += s nimi) to (většinou) umí.

Když budete chtít být skutečně zlí ^_~ , tak někde do kódu napište:

xs =+ x

Bude-li proměnná x číslo, můžete nešťastníka luštícího váš kód na chvíli beznadějně zmást, než mu dojde, že uvedený kód se naparsuje jako xs = +x, což pochopitelně neznamená nic jiného než prosté přiřazení xs = x…

Uznávám, tohle není pythoní specialita. Ale v pythoním kódu jsem ji viděl poprvé, takže sem patří :-)

Na podobném písečku operuje kopírování stávajících versus vytváření nových objektů. V tomto příkladě kopírujeme stejný objekt třikrát..

>>> xs = [[1,2,3]] * 3 >>> xs [[1, 2, 3], [1, 2, 3], [1, 2, 3]] >>> xs[0][1] = 'Baf!' >>> xs [[1, 'Baf!', 3], [1, 'Baf!', 3], [1, 'Baf!', 3]]

..zatímco v tomto třikrát zavedeme objekt nový:

>>> xs = [[1,2,3] for _ in range(3)] >>> xs [[1, 2, 3], [1, 2, 3], [1, 2, 3]] >>> xs[0][1] = 'Baf!' >>> xs [[1, 'Baf!', 3], [1, 2, 3], [1, 2, 3]]

Někdy se hodí první, ale často budete čekat spíše to druhé. Poučení? Generátorová notace rulez! Opět ^_^

Těžko říct, zda je tohle ošklivý podraz nebo šikovná vlastnost:

>>> xs = [1,2,3,4,5] # Ptát se na neexistující prvek se nevyplácí: >>> xs[4] 5 >>> xs[5] Traceback (most recent call last): File "<stdin>", line 1, in <module> IndexError: list index out of range # Vyrábět neexistující výřez je ale povoleno: >>> xs[4:] [5] >>> xs[5:] [] PS: Po zpracování několika bioinformatických problémů začínám měnit strany směrem k šikovné vlastnosti ^_~

Přihlaste se, kdo jste věděl, že insert() na neexistující index nevyhodí IndexError, ale místo toho udělá tohle:

>>> xs = [1, 2, 3, 4, 5] >>> xs [1, 2, 3, 4, 5] >>> len(xs) 5 >>> xs.insert(100, 'vpravo') >>> xs [1, 2, 3, 4, 5, 'vpravo'] >>> xs.insert(-100, 'vlevo') >>> xs ['vlevo', 1, 2, 3, 4, 5, 'vpravo']

Já tedy ne ^_^ Mimochodem je to testováno v oficiálních testech, takže je to očekávaná vlastnost…

Při importu modulů prohledává Python postupně všechny cesty uvedené v seznamu sys.path, počínaje místem spuštění skriptu. Protože je to obyčejný seznam, můžete být v pokušení ho v případě potřeby upravovat z běžícího programu. Většinou to bude fungovat naprosto v pohodě, ale jakmile se pokusíte spustit pythoní skript relativním voláním z jiného adresáře (třebas jako python3 cesta/skript.py), beznadějně to selže :-(

Zákeřnost tohohle podrazu spočívá především v tom, že by člověk čekal, že fungovat bude, zvlášť když je to napsané v dokumentaci, že…

PS: Upravit tento seznam je proto nejlepší nějak systémově – například úpravou proměnné prostředí PYTHONPATH nebo zanesením požadovaných cest do vhodného pth-souboru.

Velká skupina překvapení (a podrazů) je vázána na použití tříd, a to nejlépe ještě mícháním „starých“ a „nových“ tříd ve dvojkovém Python'u.

Řekněme si rovnou na začátku, že používat třídy v Python'u má smysl jenom v tom případě, že to skutečně jinak rozumně nejde. (Ostatně velká část samotné standardní pythoní knihovny se bez tříd zcela obejde – často jen pouhé inteligentní rozdělení kódu do modulů a podmodulů vyřeší spoustu případů, kde by se jinak člověk hrnul do použití tříd.) Python není primárně OOP-jazyk, a tak nejen že použití tříd představuje slušnou paměťovou a časovou zátěž (ne že by na tom v běžném Python'u nějak extrémně záleželo), ale bohužel se dokonce dají v pythoních třídách vyrábět takové s odpuštěním prasárny, že by jeden brečel.

Ovšem někdy jsou třídy zdaleka nejlegitimnější způsob řešení daného problému, a pak je třeba vědět, jaké překážky vám v nich Python přichystal.

Pravděpodobně asi největším průšvihem (zvláště pro lidi zvyklé na OOP z jiných jazyků, čístě OOP, jazyků) je to, že uvnitř pythoních tříd si můžete volat naprosto cokoliv a odkudkoliv. Třeba i místo initu rodičovské třídy nějaký úplně jiný kód:

TODO