Novinky v Python 2.5

12. 12. 2006 | Michal Vyskočil | Programování | 6067×

Před nějakým časem vyšla nová verze Pythonu. Pokud vás tento jazyk zajímá, pojďte si přečíst seznam změn jako jsou podmíněné výrazy, podpora pro partial funkce nebo try-catch-finally.

Jazyk Python prochází neustálým vývojem. Ovšem po revolučních změnách, jako new-stylled classes v Pythonu 2.2, se tvůrci soustředí spíše na postupnou evoluci. Nicméně i ve verzi 2.5 se najdou výrazné změny, jako například konstrukce with nebo předávání parametrů do generátorů. Novinky této verze shrnuje dokument whatsnew25.html na oficiálních stránkách Pythonu.

Požadavky na nové rysy jazyka jsou shrnuty v takzvaném PEPu, což je Python Enhancement Proposal. Jedná se o obdobu Apocalypse v Perlu nebo RFC pro Internet. Každé vylepšení má tedy přiřazeno číslo dokumentu, které je podrobně popisuje.

Podmíněné výrazy

Mnoho jazyků nabízí speciální ternární operátor, který umožňuje zapsat výraz typu pokud platí podmínka cond, přiřaď true_val, jinak false_val. Python nic takového neobsahoval a bylo nutné používat podmínky:

if cond:
    x = true_val
else:
    x = false_val

V konferencích comp.lang.python a python-dev proběhlo mnoho vzrušených diskusí především mezi zastánci tradičních ternárních operátorů z C a těmi, kteří nechtěli přidávat další syntaktické prvky, ale využít ty stávající. Guido Van Rossum se nakonec přiklonil k této syntaxi:

x = true_val if cond else false_val

V tomto případě ovšem došlo ke zkomplikování vyhodnocení kódu. Nejprve se vyhodnotí podmínka uprostřed a na jejím základě dojde k vyhodnocení jedné ze dvou krajních hodnot. Tato syntaxe vypadá divně a složitě. Jaký je důvod mít podmínku uprostřed a ne na prvním místě jako v C? K rozhodnutí došlo potom, co se porovnávala čitelnost nové syntaxe v modulech standardní knihovny. Vývojáři došli k názoru, že zápis x přiřaď true_val pokud platí podmínka cond, jinak false_val odpovídá běžnému způsobu uvažování.

PEP 308, Conditional Expressions
PEP napsal Guido van Rossum a Raymond D. Hettinger; implementoval Thomas Wouters.

Modul functools

Modul functools obsahuje nástroje pro podporu funkcionálního stylu programování. Jednou z užitečných funkcí je partial, která umožňuje za běhu vytvářet varianty již existujících funkcí. Mějme funci f(x, y, z) a z ní si (dynamicky za běhu) vytvoříme g(f(1, y, z)).

Funkce je deklarována takto: partial(func, arg1, arg2, ... kwarg1=value1, kwarg2=value2) a vrací volatelný objekt, takže se chová úplně stejně jako klasická funkce (což je pochopitelně také volatelný objekt).

import functools

def log(subsystem, message):
    return "%s: %s" % (subsystem, message)

server_log = functools.partial(log, subsystem='server')

print server_log('unable to open socket')

Další funkcí je update_wrapper, která umožňuje skrýt vnořené funkce. Například dekorátory se v Pythonu skládají z vnější a vnořené funkce a pokud dojde k chybě ve vnořené, vypíše se jako příčina chyby ona. Toto (logické) chování ovšem může být matoucí, protože se ve výpisu objeví chyba ve vnořené funkci, která se v kódu neobjevuje. Tato funkce potom zkopíruje jméno, modul a dokumentační řetězec do vnořené funkce, takže se ve výpisu chyb objeví pouze vnější funkce.

def my_decorator(f):
    def wrapper(*args, **kwds):
        print 'Calling decorated function'
        return f(*args, **kwds)
    functools.update_wrapper(wrapper, f)
    return wrapper

Případně je možné použít dekorátor wraps:

def my_decorator(f):
    @functools.wraps(f)
    def wrapper(*args, **kwds):
    ...

PEP 309, Partial Function Application
PEP navrhl a sepsal Peter Harris; implementoval Hye-Shik Chang a Nick Coghlan, upravil Raymond Hettinger.

Absolutní a relativní importy

Malá část tohoto vylepšení je už v Pythonu 2.4, kdy závorky v konstrukci from ... import ... zjednodušily a zpřehlednily import mnoha jmen, protože se dají zapsat na jednom řádku. Důležitější část je implementována ve verzi 2.5 - relativní nebo absolutní importy. V budoucích verzích Pythonu by se měly používat právě absolutní importy jako výchozí způsob. Dejme tomu, že máme adresář balíčků jako je tento:

pkg/
pkg/__init__.py
pkg/main.py
pkg/string.py

Balík pkg obsahuje moduly pkg.main a pkg.string. Mějme kód v modulu main.py. Co se stane, pokud se v něm provede výraz import string? V Pythonu verze 2.4 a nižší se systém nejprve podívá do adresáře balíčku (pkg) pro provedení relativních importů, najde pkg/string.py, naimportuje soubor jako modul pkg.string a sváže ho se jménem string ve jmenném prostoru modulu pkg.main. To je zcela v pořádku, pokud chcete importovat pkg.string. Ale co v případě, že chcete použít standardní modul Pythonu? Bez hacků, jako je prohledávání sys.modules, to prostě nejde. Holger Krekel vytvořil balíček py.std, který nabízí čistší způsob. Můžeme napsat import py; import py.string.join(). Nevýhodou je, že není standardní součástí všech instalací Pythonu.

Od verze 2.5 jazyk podporuje změnu chování importu. Je nutné napsat direktivu from __future__ import absolute_import a import začne nejprve prohledávat standardní knihovnu Pythonu. Plánuje se, že od verze 2.7 to bude výchozí nastavení.

Relativní importy jsou stále dostupné a to přidáním tečky před jméno modulu při použití konstrukce from ... import:

# Importuje jmena z pkg.string
from .string import name1, name2
# Importuje pkg.string
from . import string

Teď se importuje modul string relativně k současnému balíčku, takže v pkg.main se naimportují name1 a name2 z pkg.string. Přidáním dalších teček můžeme posunout počátek importu i na předka našeho balíčku:

from . import D                 # Importuje A.B.D
from .. import E                # Importuje A.E
from ..F import G               # Importuje A.F.G

Je důležité si uvědomit, že toto chování se netýká konstrukce import, pouze from ... import.

PEP 328, Imports: Multi-Line and Absolute/Relative
PEP sepsal Aahz; implementoval Thomas Wouters.

Konstrukce try/except/finally

Do verze 2.4 bylo možné používat konstrukci try dvěma způsoby. Buď používat blok finally nebo jeden či více bloků except pro zachycení výjimek. Nebylo možné zkombinovat blok(y) except s blokem finally. Bylo tomu tak proto, že vygenerování správného bytecode pro tuto konstrukci není jednoduché a navíc se tvůrcům zdála sémantika poněkud nejasná. Ovšem Guido van Rossum jistý čas dělal v Javě, která tuto kombinovanou konstrukci obsahuje, a to mu pomohlo vyřešit potíže se sémantikou.

try:
    block-1 ...
except Exception1:
    handler-1 ...
except Exception2:
    handler-2 ...
else:
    else-block
finally:
    final-block

Je vykonáván kód označený jako block-1. Pokud v něm dojde v výjimce, bude zachycena a zpracována v příslušném bloku except. Pokud nebyla vytvořena žádná výjimka, je provedena část else-block. Bez ohledu na to, co se stalo předtím, je část označená jako finally-block vykonána vždy a to i v případě, že kód handler-1, handler-2 nebo else-block vygeneruje další výjimku.

PEP 341, Unifying try-except and try-finally
PEP sepsal Georg Brandl; implementoval Thomas Lee.

Závěrem

Dále v Pythonu proběhla řada dalších změn, jako je konstrukce wich, nová základní třída pro výjimky, další speciální metody, konstrukce yield se stala výrazem a mnoho dalších. Další díl se bude věnovat změnám nejvýraznějším, vylepšeným generátorům a konstrukci with.

       

Komentáře

[Jiří P.]

Ternarni operator jsem nahrazoval fintou

cond and true_val or false_val

[Kyosuke]

Ano, skvěle pythonovsky čitelné.

[Viktor Lieskovsky]

Ano, ale pre zaporne true_val hodnoty si treba pomoct trikom s listom:

(cond and [true_val] or [false_val])[0]

Viac v diveintopython.

[Jan Molic]

Došel jsem k tomu, že nejrychleji čitelné jsou víceřádkové konstrukce, ne zkomprimované jednořádkové výrazy. Ty sice na první pohled vypadají jednoduše, ale člověk si je musí dekódovat, což zabere více "mozkového" času. Proto raději píšu ukecaně

if cond
   x = 1
else
   x = 2
end

[Ladicek]

A já si zase chrochtám blahem, když můžu (v Ruby) napsat xxx = yyy if zzz. Nevím, zda je v Ruby i nějaká else část, to už bych asi zas tak nadšený nebyl, ale je pravda, co se tvrdí v článku: je to mnohem bližší přirozenému uvažování.

O chvilku později… pravda, mluvíte vlastně o čtení. Je fakt, že podmínku utopenou kdesi za výrazem můžu snadno přehlídnout… teda mohl bych, kdybych nepoužíval Ruby akorát na skriptíky zvící max. desítek řádek. Ale něco na tom bude.

[disorder]

ale ved v ruby mame

(cond)?(x=1):(x=2)

:)

[Ladicek]

Uff, tohle mi bylo doteď utajeno a ani mi moc nevadí, že jsem to nevěděl. Tenhle zápis se nejen blbě čte, ale i píše, fakt ne, dík

[disorder]

ale ved prave o tom tu je rec :)

http://en.wikipedia.org/wiki/Ternary_operator

[disorder]

a este ti nedoslo, ze ho mozes pouzit aj uprostred nejakeho vyrazu, ako argument a tak :)

[rane]

to môžeš v ruby urobiť zo všetkým, pretože v ruby je všetko výraz, takže napríklad moje obľúbené:

x = if cond then 1 else 2 end

[disorder]

si prasa :P

ale nikdy by ma nenapadlo, ze to v ruby prejde...

[Kyosuke]

Jaké prase? Je to jako v Lispu, všechno vrací hodnotu a jestli ji člověk použije nebo ne, je jen na něm. Myslím, že se to netýká jen if. A prvky jazyka jsou ortogonální a dají se kombinovat. Aspoň je to konzistentní a logické. Ať se pythonisté třeba vztekají a stavějí na hlavu.

[disorder]

viem, ze vsetko vracia hodnotu, je to napr. krasne vidiet v irb.

[Kyosuke]

Mimochodem, mě tohle překvapuje, že by to někoho nenapadlo. Ruby se mi líbí specificky kvůli právě takovýmhle věcem. Stejně tak dobré důvody, proč jít do Ruby, jsou bloky, otevřené třídy a podobně – prostě ty věci, které Ruby zdědilo z „experimentálnějších“ jazyků a které se snaží protlačit do mainstreamu. A zdá se, že to takhle chápe spousta lidí. Pokud Ruby používáš a používání příkazů jako výrazů Tě nikdy nenapadlo, napadá mě, jestli jsi na ten jazyk nenarazil spíš náhodou než cíleně.

[rane]

Hej, toto ale hlavne bloky a otvorené triedy sú pre mňa najzásadnejšie vlastnosti ruby. Keby sa ich podarilo pretlačiť napríklad do takého php (ktoré som nútený používať v práci), to by bol raj

[disorder]

cpat if-then-else-end napr. ako argument? chod s tym niekam. to by ma ani v nocnej more nenapadlo (a uz vobec nie pchat to na jeden riadok, ble). a uz vobec nie ked mam k dispozicii ?:

fuj

[Kyosuke]

Hm, perly sviním…

[disorder]

prasata ste tu vy a tie "perly" si po sebe citajte sami... :P

[Kyosuke]

Můj názor je, že nepoužívat jen kvůli pofidérním subjektivním motivům vyjadřovací prostředky jazyka (pointerovou aritmetiku v C, regexpy v Perlu, návatové hodnoty v Lispu a Ruby, objekty v C++, vnitřní třídy v Javě, generátory v Pythonu) alespoň na těch místech, kde to má smysl, je jako používat šroubovák na páčení a nůž na šroubování. Taky to jde, ale s větším úsilím, než je nezbytně nutné, a člověk se pořád o něco okrádá. A kromě toho, neidiomatický kód se IMHO čte hůř :-p When in Rome, do as the Romans do.

[disorder]

pis si podmienky k argumentom, ja ti branit nemam ako, ale nadavat ti budem :P a neprezentuj to tak vznesene, pretoze je to odporne. tvaris sa akoby ten ternarny operator neexistoval - preboha, ved je to zmysel jeho existencie...

[Kyosuke]

Umělý smysl jeho existence, zapomněl jsi dodat. Samozřejmě, jazyky rozlišující výrazy a příkazy nemají moc na vybranou, ale to je jejich problém, ne můj.

[disorder]

tak preco v ruby vobec je, ked je taky umely a ruby tak cisty, ha?

[Kyosuke]

Protože Ruby z Perlu zdědilo TIMTOWDY.

[disorder]

nie, iba tam bol umyselne pridany, pretoze tak to je spravne.

teraz pravdu: naozaj by si ten if pouzil?

[Kyosuke]

Nevidím v tom problém, zvlášť, když bych v něm chtěl třeba sekvencovat kus výpočtu a celé to někam předat a nezatěžovat se s vymýšlením nějakých názvů proměnných. Prostě jako v Lispu, normálka.

[rane]

Presne tak, ja to tak používam bežne a bez akýchkoľvek výčitok svedomia

[disorder]

takze by si vybral nieco ako

bla(if (nil) then 0 else 1 end)

namiesto

bla((nil) ? (0) : (1))

[Kyosuke]

Já bych nejradši bral…

(bla (if nil 0 1))

…ale každému, jak je libo. Ne, v bezzávorkovém jazyku, jako je Ruby, je lepší na pouhé dvě hodnoty a jednoduchou podmínku použít podmíněný výraz, páč ty dva znaky znamenají méně balastu, ale ne všechno je takhle jednoduché, že.

[disorder]

ak mas normalny editor, lahko vidis kde ti zatvorky zacinaju/koncia a tie slova su naozaj redundantne a zvysuju neprehladnost (nie nadarmo sa normalne odsadzuju a odriadkovavaju). uz sa nevykrucaj :P

[Kyosuke]

„ak mas normalny editor, lahko vidis kde ti zatvorky zacinaju/koncia a tie slova su naozaj redundantne a zvysuju neprehladnost“

Díky, přidám si Tě na seznam obáhjců Lispu, tohle pořád tvrdím.

[disorder]

keby si trochu neprekrucal vyznam :) proti lispu nic nemam ale ovladam ho zatial iba tak aby som vedel co mam v ~/.emacs :)

[mykhal]

myslím, že je škoda, že nejde udělat print "OK" if cond, protože else část je povinná. takže člověka hned napadne print "OK" if cond else pass, což je špatně, protože se nerozhoduje o provedení příkazu print, ale o jeho argumentu, což mi nepřijde vždy úplně intuitivní. Takže jestli tomu rozumím, touto novou syntaxí ekvivalent if cond: print "OK" zapsat nelze .. (?)

[Michal Vyskočil]

Moc jsem z toho nepochopil, ale pokusím se odpovědět.

Ternární operátor slouží pro výrazy, takže příkaz print "OK" není na tomto místě povolen (Python v tomto ohledu dodržuje algolovské rozdělení příkazů a výrazů). Je pravda, že část else by mohla být nepovinná a fungovat by to mohlo asi takto. Nechce to někdo navrhnout?

a = 5 if cond else None

No a ten if cond: print "OK" napsat jde i ve 2.5

[mykhal]

nevím jak vám, ale mě to python normálně povolí ..

[Michal Vyskočil]

Aha, omlouvám se, je to print "OK" if True else None ... já tam pořád cpal ham = print .... Ale právě ta větev else None tam být musí, přitom zbytečně

[Kyosuke]

BTW, co dělá konstukce „witch“? Pořádá v ctihodném aplikačním serveru divoký sabbat?

[Michal Vyskočil]

No a pak, že není Python kouzelný . Takový krásný překlep ...

[finc]

Python je velice zajímavá věc. Jediné, na co se nedokážu odvyknout jsou složené závorky, to mi na rozdíl od odsazování příjde přehlednější (samozřejmě odsazování ke kodu patří). :(

[Marek]

Me take. (Nejen)proto pouzivam Ruby. Jak je videt z tohoto clanku, Python se porad vic Ruby priblizuje.

[Mikos]

To mě tedy naopak "2D syntaxe" vyhovuje neskonale více než složené závorky. Je to jedna z věcí kvůli které Python miluju...

[neurol23]

uz python umi opravdu paralelni programy?

[pepr]

A co jsou podle tebe "opravdu paralelní programy"?

[neurol23]

no vim, ze python mel omezeni, ze i pri pouzivani vice vlaken, mohlo v jednom okamziku bezet pouze jedno vlakno (a to i na viceprocesorovych ci vicejadrovych strojich), coz je v case core2duo apod. dost blby omezeni

existuje sice stackless python (http://www.stackless.com/), kterej tohle omezeni nema, jenze s tim se clovek v bezne praxi nesetka (o jeho "rozsirenosti" bohuzel hovori i fakt, ze pro nej neexistuji balicky pro zadnou distribuci , aspon o zadnych nevim)

[MarSik]

Docela by me zajimalo, jestli jste uz nekdo zkousel volani funkci z externich dynamickych knihoven (ctypes modul), ja se k tomu zatim nedostal, ale brzo to planuju.

[odolmed3]

Diky za clanok, aspon nemusim kvoli novym vlastnostiam lustit PEPy. Dokumentacia k novym featuram je dost biedna a knihy ktore su na trhu pokryvaju nanajvys Python 2.3.