Přejít k navigační liště

Zdroják » Různé » Python 3 může oživit Python. Ale nemyslí si to všichni.

Python 3 může oživit Python. Ale nemyslí si to všichni.

Články Různé

Od vydání Pythonu 3 na konci roku 2008 uběhlo už hodně času, přesto je to s jeho popularitou poněkud vlažné. V poslední době se dokonce začínají objevovat nové články o tom, že by se mělo pokračovat s vývojem Pythonu 2, protože Python 3 nepřináší nic převratného a přechod na něj je zbytečně náročný (ať už časově či finančně). To však může vést k roztříštění komunity a není to nejlepší vizitkou pro jazyk jako takový.

Nálepky:

Python 3 dělá práci programátora příjemnější

Z vlastní zkušenosti můžu říct, že je pro mě Python 3 jazykem, který můžu mít rád a který mně neháže klacky pod nohy. V Pythonu 3 byly odstraněny některé nejednoznačnosti a programátor tak nemusí myslet na tolik okrajových případů, které by mohly nastat. Celkově to vede k mnohem příjemnějšímu pocitu z programování, nemluvě o nových funkcích, které do Pythonu pomalu přibývají s každou novou verzí. Z verze 3.4 určitě stojí za zmínku asyncio, které má slušný náběh k tomu, aby sloužilo jako základ nových asynchronních aplikací.

Spousta lidí si stěžuje na nedostupnost knihoven pro novou verzi, v praxi to ale často není tak špatné, jak by se mohlo zdát. Dnes je již naprostá většina těch nejpoužívanějších knihoven (alespoň webových) vydávána s podporou pro Python 3 a pro běžného vývojáře, který nepracuje s nízkoúrovňovým kódem dané knihovny, je tato podpora plně transparentní. Dobrým příkladem je Django, které běží s totožnou funkcionalitou na obou verzích jazyka a programátor většinou nepozná rozdíl.

Nutno dodat, že je zde i spousta zastaralých knihoven, které nefungují ani na nejnovější verzi Pythonu 2, převážně kvůli špatnému návrhu a nedostatku času autorů je dále udržovat. Tato skutečnost ve mně ale spíše umocňuje fakt, že s poměrem funkčních knihoven pro verzi 2 a 3 to není tak hrozné. Naopak Python 3 je v tomto směru ještě hodně čistý a nově psané knihovny pro Python 3 jsou aktivně udržovány.

Portování kódu není nadlidský úkol

Někdo to může považovat za nutné zlo, ale jednotlivé verze jazyka nejsou zase tak odlišné, aby portování zabralo úsilí, které by se nevyplatilo. Největší problém samozřejmě budou mít vývojáři, kteří v aplikaci hodně pracují s řetězci nebo s nízkoúrovňovým síťovým API. Někteří z nich si i veřejně postěžují, potom ale stejně napíší aplikaci kompatibilní s oběma verzemi jazyka. Konstruktivní komentáře jsou však tím, co posunuje jazyk dopředu a je potřeba si jich vážit. Možná by jen někdy mohly být prezentovány trochu jiným způsobem.

Existují nástroje, které si kladou za cíl usnadnit kompatibilitu pro obě verze Pythonu (six), nebo jednorázově pomoci převést kód z verze 2 na verzi 3 (2to3). Ten druhý z nich sice občas nefunguje bez manuálního zásahu, usnadní však spoustu práce a dokáže zpracovat minimálně ty změny, které bychom jinak museli roboticky přepisovat. Pokud hledáte ucelený zdroj informací o tom, jak portovat, můžete sáhnout po knize Porting to Python 3: An in-depth guide, případně po stručnějším, ale uceleném průvodci Porting to Python 3 Redux.

Řetězce v různých verzích Pythonu

V Pythonu 2 existují textové typy str a unicode, přičemž k str se interpret chová jako k binární reprezentaci řetězce, tedy téměř jako k náhodným bajtům. V praxi to potom znamená následující:

>>> len("čeština")  # str
9
>>> len(u"čeština")  # unicode
7
>>> print("čeština"[1:])  # str s nevhodně zvoleným ořezem
�eština

Toto chování může být pro začátečníka matoucí, proto se Python 3 snaží tento problém řešit tak, že nově se textové typy chovají jako textová unicode data. Pro práci s textovými daty je zde typ str, pokud potřebujeme pracovat s daty jako s bajty, je zde typ bytes. Pokud specifikujeme kódování, je možné mezi jednotlivými typy i snadno převádět. Důležitý je ale fakt, že v případě práce s textem se můžeme spolehnout na to, že se k tomuto typu budou i všechny ostatní funkce patřičně chovat. Nečekají na nás tak podobná úskalí jako v ukázce kódu výše. Sjednocení typů vedlo i ke sjednocení speciálních metod u třídy, takže namísto __str__ a __unicode__ už pro textové řetězce stačí použít univerzální __str__.

Malé věci, které dohromady dělají velký rozdíl

Ačkoliv byla velká část nových funkcí zpětně portována pro Python 2, stále zůstala funkcionalita, která je dostupná jenom v Pythonu 3. Standardní knihovna prošla sjednocením, byly odstraněny moduly jako md5 (nyní součástí hashlib), urlparse (nyní jako urllib.parse) a spousta dalších. V důsledku to vede ke zpřehlednění a odstranění duplicit. Všechny moduly standardní knihovny navíc nyní mají nativní podporu pro unicode (nově například csv).

sets jsou nyní součástí jazyka a není potřeba používat externí modul, třídy jsou implicitně vytvářeny v “novém stylu” (můžeme se vyhnout odvozování od object) a přidáním nové možnosti formátování řetězců se jazyk ještě více odděluje od vlivu jazyka C, kterým bylo předchozí formátování nepochybně inspirováno. Formátování řetězců je tímto zjednodušeno na úroveň šablon, které jsou podobné těm, které známe z webu. Tato funkcionalita byla pro svou užitečnost zpětně portována i do Pythonu 2. Osobně považuji za velmi užitečnou i integraci virtuálních prostředí (virtualenv) přímo do standardní knihovny, protože to usnadňuje práci s knihovnami různých verzí a umožňuje vytvářet “sandboxy” pro různé projekty.

Větší využití iterátorů

V Pythonu 2 jsme byli zvyklí na range a xrange, zip a itertools.izip, filter a itertools.ifilter. Všechny se používaly ke stejnému účelu, ale každá verze měla svá specifika. Python 3 používá pouze range, zip a filter, které se nově chovají jako iterátory. Nemusíme se tak bát použít následující zápis:

is_even = lambda n: n % 2 == 0
even_numbers = filter(is_even, range(10**100))

with open('even_numbers.txt', 'w') as f:
    for number in even_numbers:
        f.write('{}\n'.format(number))

Zatímco Python 2 na tomto kódu skončí s OverflowError: range() result has too many items, Python 3 tento kód zpracuje a začne zapisovat sudá čísla do souboru. Dokonce i při změně na xrange a itertools.ifilter Python 2 skončí s chybovou zprávou OverflowError: Python int too large to convert to C long, to kvůli implementačnímu detailu funkce xrange. Příklad sám o sobě příliš užitečný není (jedná se spíše o ukázku filter a range), změna na iterátory má však v praxi mnoho uplatnění. Díky implementaci PEP 380  do Pythonu 3.3 je navíc možné tyto funkce využít i v kombinaci s yield from syntaxí. V interaktivním shellu navíc zůstala zachována čitelnost:

>>> range(100)
range(0, 100)

Nebojte se Python 3 použít pro svůj nový projekt

Python 2 pro stávající projekty funguje dobře a není nutností přecházet na novou verzi. Letos byla oznámena podpora pro Python 2 až do roku 2020. Pokud ale plánujete váš projekt udržovat dlouhodobě, začnete nad přechodem na Python 3 minimálně přemýšlet. Nebo se alespoň pokuste psát kód tak, aby byl kompatibilní s Python 3. Pokud si chcete otestovat závislosti vašeho projektu, můžete použít nástroj caniusepython3.com. Nová verze Pythonu 2 se však neočekává.

Pro zcela nový projekt by měl být Python 3 jasnou volbou. Pokud váháte a zatím jste v Pythonu 3 nic nezkusili, doporučuji shlédnout loňské video z Pycon 2013: Python 3.3: Trust Me, It’s Better than 2.7.

A věřte mi, je lepší než 2.7.

Článek je založen na osobních názorech autora, doplněných autory Python 3 can revive Python a How keep Python 3 moving forward.

 

Komentáře

Subscribe
Upozornit na
guest
21 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Ondřej

Pokud naleznu nějakou knihovnu / nástroj (třeba statický analyzátor kódu atp.), mám větší šanci, že bude pro Py2 nebo pro Py3? Pokud pro Py2, tak pak nevidím důvod pro použití Py3. Vychytávky v Py3 jsou určitě hezké, ale jsou to v podstatě minoritní syntaktické detaily, na kterých až tak nezáleží — alespoň ne ve srovnání s tím, že v Py3 přijdou o nějakou důležitou knihovnu/nástroj. A pokud pro Py3, tak pak nevidím důvod pro použití Py2.

Takhle to vidím já :-)

Ondřej

…a já doufám, že si ani zvykat nebudou muset a že přechod na nějaký Py4 už proběhne ve větším klidu :-).

Já právě začal kdysi Py3 používat, tehdy snad ve verzi 3.2 a to prostě bylo peklo, najít bezproblémovou knihovnu pro Py3 byl téměř nadlidský úkol, takže po dopsání jedné rozepsané aplikace jsem rychle přešel zpátky na Py2 a od té doby jsem tam zůstal a na problém nenarazil. A pokud pořád není více knihoven pro Py3, tak přechod k němu pro mě nemá význam. Ale já zase Python používám jen na takové to domácí programování…

Bruce

Ak robim novy webovy projekt, pouzivam uz Python 3 a az na niektore vynimky je to uz dnes bez problemov. S prichodom Djanga s podporou Python 3 mi pride, ze sa vela balikov rozhybalo a tiez pridali podporu, pretoze to uzivatelia vyzadovali a posielali pull requesty.

V dvojkovej verzii som casto narazal na unicode problemy, v trojke je to konecne poriesene a to by som urcite za detail nepovazoval.

sachy

Překvapuje mě, že někdo doporučuje psát v jazyku, který je po updatu specifikace zpětně nekompatibilní sám se sebou :)

Bruce

Vacsina jazykov sa raz dostane do bodu, kedy musi spravit spatne nekompatibilne rozhodnutie, tak to uz totiz chodi. Svet nie je dokonaly. Pisat sa v nom pise vyborne, nevidim dovod ho nedoporucovat.

Miloslav Ponkrác

Nedostane. Seriózní jazyk tohle po delší době existence prostě neudělá nikdy. Proto se dodnes používá Fortran, C, C++ a řada dalších jazyků, které neblnou jako Python.

Mimochodem právě krok Rossuma, který začal vážně uvažovat o nekompatibilní změně základních věcí v jazyce (tedy v době, když ještě Python 3 neexistoval) mě přinutil okamžitě stopnout jakékoli další pokračování projektů v Pythonu. A to jsem do té doby používal jen a pouze Python. Dodnes tohoto rozhodnutí nelituji, považuji ho za správné a nejlepší možné.

Programovací jazyk, který nedává záruku ochrany práce programátorů, by se měl používat jen na skriptování, kterým potřebujete udělat momentální úkol a pak ho zahodit. Raději budu trávit čas s rodinou, přáteli či zlepšováním projektů, než s jazykem, který nekompatibilně zasahuje do základních konstrukcí svého jazyka.

Stejně jako Python blbnul Perl, kdysi velmi používaný jazyk, a dnes je z něho okrajový, mnohem méně známý jazyk. Právem.

Život je krásný příliš na to, aby ho člověk trávil s programovacími jazyky neshcopnými udržet základní zpětnou kompatibilitu.

Ing. Miloslav Ponkrác

kotekl

On v tom celém sehrál trochu paradoxní úlohu Python 2.7, nejenom, že přinesl mnoho vlastností ze trojky, aby usnadnil budoucí přechod, ale zároveň omezil důvody, proč na trojku vůbec přecházet. (Teď mě nechápejte špatně, s vyzněním článku v zásadě souhlasím.)

jiri.vrany

Vidím to podobně. To co považuju na trojce za opravdu dobré, máme i ve 2.7.

pb

Bohužel, ty věci, na které Mitsuhiko v poslední době přichází jsou takový maso, že je snad dobře, že se ten Python3 zatím neujal. Mě se to vyčištění samo o sobě líbí, ale ohledně toho unicode mám dojem, že autoři si nějak mysleli, že se na sebe budeme všichni hodně hezky usmívat, a budeme na sebe navzájem strašně hodní. Jenže tak to ve skutečnosti nebude.

rbt

Jelikoz to pisu znovu, protoze tu nemate osetrenou situaci prohlizec bez jvascriptu a bez varovani jsem tak o pripsevek prisel, budu ted hodne strucny.

Python 3 prinasi jen castecne odstraneni chyb v navrhu a historickych reliktu. S backportovanymi vlastnostmi do 2.7 se atraktivita pro prechod jeste dal snizuje. Ani implementace referencniho CPythonu neprinesla nic zasadniho. GIL zustal tak na skutecne vicevlaknove aplikace muzeme zapomenot (ne vsude lze nasadit Jython). Virtualni stroj je zhruba stejne pomaly jako u 2.x, aspon podle vsech dostupnych benchmarku. Garbage collector taky zustal s neefektivnim pocitanim referenci, pritom i takove Ruby se pochlapilo a v posledni verzi maji vlastni verzi generacniho GC a na vykonu to je sakra znat.

Cekal jsem neco zasadnejsiho, jako zbaveni se vestavenych fci a jako len(), any(), all(), raw_input() a nemuset neobjektove zjistovat delku kolekece jako len(obj) nebo chlupateho obj.len() ale logickeho obj.len(). Zkriplena verze lambdy taky zustala a porad nelze pouzit nic nez jeden vyraz (bez prikazu) a nefunkcni uzavery.
Ocekaval bych i zavedeni viditelnosti metod trid, zachovani reduce() a nemuset obchazet for cyklem nebo zacleneni uzitecnych a notoricky vyuzivanych funkci z modulu itertools do tridy generatoru/seznamu. To jsou ale veci diskutabilni, na rozdil od predchoziho odstavce.

Tak snad az Python 4.x K Py3 me prinuti jen nekompatibilita klicovych knihoven s radou 2.x.

rbt

Melo byt samozrejme

len(obj) nebo chlupateho obj.__len__() ale logickeho obj.len()

Miloslav Ponkrác

Protože toto jsou operátory a ty se obvykle nevolají jako metoda objektu v zápise zdrojového kódu.

Stejně jako příšete a + b, a ne a.add(b), tak se některé věci berou jako operátory a volají se „neobjektově“.

rbt

Protože toto jsou operátory a ty se obvykle nevolají jako metoda objektu v zápise zdrojového kódu.

Tak to se ale sakra mylite. len, any, all a spousta dalsich fci z *__builtins__* nejsou zadne operatory, ale cistokrevne globalni funkce, ktere se historicky tahnou z predchozich verzi pythonu.

Tester2

Ja som v pythone novacik a nevidim dovod ucit sa starsiu verziu ked je k dispozicii nova. Dost ma frustruje aj to, ze na webe je mnoho roznych prikladov kodu, ktore su ale pre verziu 2.x, nefunguju teda vo verzii 3.x, a kym to zistim, lebo casto to tam nie je uvedene, tak sa s tym dost natrapim a je to velke minus pri rozhodovani ci v tom pokracovat, ale zas velkym plus je univerzalnost pythonu s ohladom na operacne systemy a jeho moznosti.
Podla mna bolo velkou chybou, ze sa s verziou 2.x neskoncilo tam kde povodne bola a dorabali sa do nej veci, ktore su vo verziach 3.x. Takto nie su motivovani stari harcovnici aby presli na novu verziu a nas novacikov to dost matie a zneistuje v prvych krokoch.

Miloslav Ponkrác

Největší chyba bylo, že Rossum, autor Pythonu, udělal ten velmi nerozumný krok, a vůbec zavedl zpětnou nekompatibilitu v programovacím jazyce po 17 letech. Větší chyba v Pythonu nikdy udělána nebyla.

Navíc si myslím, že ta změna mezi 2 a 3 nemá takové benefity, aby to ospravedlňovalo rušení zpětné kompatibility.

Martin Prokeš

Já už to zažil jednou u Perlu, takže je mi bližší tento text: http://hiltmon.com/blog/2014/01/04/python-its-a-trap/

snajpa

Donutte distributory vyhodit python 2.7 z linuxovych distribuci a je vyhrano. To potom budou vsichni nuceni kod portovat, protoze to nebude kde pustit. Ale to nejdriv musi poumirat enterprise distra, ktere maji tak stary python. Normalni kolobeh zivota v opensource, staci videt souvislosti :)

Miloslav Ponkrác

A nebo se většina lidí na Python vykašle namísto portace, což je daleko reálnější scénář.

Jedna věc jsou bastlíři-hračičkové, kteří mohou mít názory typu „normální koloběh v open source“, protože nikdy nic pořádně neudělali, a především to neudržovali po delší dobu. Druhá věc je seriózní enteprise prostředí, kde každá změna může být velmi drahá. Natož aby si ty změny ještě vyráběli uměle a zaváděli paniku a poplachu s potenciálními škodami v astronomických částkách jen pro choutky nějakého Rossuma či snajpa. Tak to v enterprise nefunguje.

Ono se hned pozná, kdo kdy něco užitečného vytvořil už podle lehkovážných názorů na destrukci a zavařování těm, co něco užitečného dělají.

Petr

Já ve vzniku P3 nevidím problém. Spíš mě mrzí, že se to nevzalo pořádně od podlahy a nebyl třeba odstraněn GIL.
Ztráta zpětné kompatibility je mrzutá, ale ne katastrofická, jak ji Ponkrác už roky nenávistně hejtuje. Programátoři tím nejsou biti, protože P2 se stále udržuje a staré projekty mohou být stále provozovány dál. Není to buď a nebo. Jen by ta ztráta kompatibility měla být vyvážena nějakým pořádným přínosem, měla by za tu mrzutost stát. Za sebemohu říct, že mi P3 nic významného nepřináší (orientuji se převážně na tvorbu podnikových desktopových aplikací) a tak stále spokojeně používám P2. Ale P3 fandím a stále čekám, kdy pro mě začne být přínosnější než P2.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.