Přece jenom, v Pythonu 2 je toho tolik, co nikdo nebude přepisovat do Pythonu 3, že přinejmenším prodloužená podpora bude potřeba ještě hóóódně dlouho. Mimochodem pokud je to na třetích stranách, tak to může být docela výnosný trh.
Python 3 je výborný jazyk, mnohem koherentnější a "čistší", než Python 2. Škoda, že se nezlepšila podpora lambda výrazů, ta je i nadále dost ubohá a je to dle mého názoru hlavní nevýhoda Pythonu proti konkurenčnímu Ruby (které má samozřejmě zase svoje nevýhody). Ano, vím, proč to tak je a jaká logika je k tomu vede, ale to nic nemění na skutečnosti, že lambdy v Pythonu proste stojí za h0vno.
NB: Pokud člověk instaluje současně python 2 i 3 v Ubuntu 17.10, je ve výchozím nastavení "python" stále ještě 2.7.14.
Python má korutiny, to je mnohem zásadnější než lambdy (Ruby, přiznávám, neznám). Často člověk potřebuje spíš implicitní kontext než tvrdý paralelismus; je hrozně příjemné být schopen implementovat kooperativní multitasking čistě standardními prostředky jazyka. Jak by tohle zjednodušilo bare-metal embedded svět, kde buď volím mezi složitým FSM (tedy explicitním kontextem) nebo RTOS (což je často overkill).
Lambdy jsou anonymní funkce, s korutinami ani paralismem nijak přímo nesouvisí. Jsou ideální pro parametry funkcí vyšších řádů, různé filtry, iterátory apod., a samozřejmě i pro zpětná volání. Ruby má plnou podporu lambd, v Pythonu jsou "ořezané" na jeden jediný výraz. Python to částečně dohání tím, že dovoluje lokální vnořené funkce, ale i tak mi to příjde jako zbytečný opruz.
Ruby obecně je velmi podobný jazyk, jako Python, ale trošku říznutý Perlem. V praxi se používá hlavně v souvislosti s frameworky Rails (webové aplikace) a Metasploit (exploity a pen testing).
pro mínusáře PEP342 -- Coroutines via Enhanced Generators
funguje to v pythonu 2.5 a novejsim
Přesně tak, Py3 je supr jazyk, ale popularita Py2 byla již v době forku podle mě podceněna a rok 2020 rozhodně nevyjde.
Článek je výborné shrnutí se zajímavými odkazy, díky, autore!
V Py2 běží taková spousta kritických, velkých nebo naopak skrytých věcí, že je to neštěstí. Psané byly v době, ze které si ještě spousta manažerů pamatuje, jak jim kluci ajťácký slibovali, že ten nový neznámý jazyk je naprosto geniální a mají k němu svolit.
Používat v IT věk nějakého nástroje jako důvod jeho změny nepovažuju za dostatečný argument. Měli bychom si naopak vážit tradice, kompromisně s pokrokem.
Python se zjevně rozpadá na 2 jazyky. Ne každý je nadšený z Pythonu 3, viz třeba http://lucumr.pocoo.org/2011/12/7/thoughts-on-python3/ - taky na to narážím.
Něco zůstane v Py2, něco bude jen v Py3. Oblíbenosti Pythonu to neprospěje.
Prosím tě, ten článek, co odkazuješ, je 6 let starý a týká se v podstatě ještě experimentální verze 3.2. Ano, tehdy byla představa, že vše automaticky vyřeší nástroj 2to3, a od té doby (v dalších verzích) přibyly do Pythonu 3 konstrukce umožňující psát jeden kód běžící v Pythonu 2 i 3.
Vše, co ten člověk (a skupina okolo něj) napsal - Flask, Click..., samozřejmě bez problému běží na Pythonu 3.
Jasně, přechází! Zrovna letos měl na PyCon CZ v Praze o Rust přednášku :)
https://www.youtube.com/watch?v=zmtHaZG7pPc
Konečně po dlouhé době snad dvojková řada zemře, vždycky si říkám, proč musím mít v systému dvě verze, když trojku máme už strašně dlouho ... BTW pánové z Redhatu budou mít docela veselo, dlouhou dobu REHL Python 3 vůbec nepodporoval a teď to budou muset do dvou let stihnout odladit.
Ještě se zbavit GIL a z Pythonu bude velice zajimavy jazyk
„Věřím, že Python 2 bohužel zůstane v repozitářích ještě velmi dlouho potom, co ho usptream „zabije“.“
Nic proti pokroku, ale není nic lepšího, než po letech vyhrabat starý projekt (ať už svůj, nebo na netu), který nemá alternativu a pak hodiny trávit snahami jej vůbec spustit.
Zrovna nedávno jsem hledal jednu „historickou“ informaci a narazil jsem na starý archiv jednoho webu, který měl databázi v SQLite (ach, ty začátky). Problém byl v tom, že to byla jakási stará, dnes nepodporovaná verze. Po nějaké době jsem to vzdal a začal přemýšlet, na co ty archivy vlastně mám. Resp. jestli bych k těm archivům neměl přidávat i kopii systému.
V (tuším) IEEE explore byl před časem článek o digitální archivaci. Jak to je velký problém i pro velké firmy. Hezký byl případ Pixaru, který měl sice zalohovane úplně všechno na co přišli, ale zapomněli si uložit seed pro rng. Následek toho byl, když chtěli dělat remaster, tak tráva nebo řasy se jim hybala úplně jinak a oni tedy (IIRC) museli platit animatory, kteří ta stébla animovali ručně.
- Je problem spustit P2 kod v P3 interpreteru, je tam zpetna kompatibilita ?
Kód musí používat jen konstrukce validní v obou verzích, pak to fungovat bude.
- Nakolik je P3 nekompatibilni s P2?
Trochu jiná povolená syntax, občas přejmenované knihovny, jiné vnímání stringů a bytů atd.
- nejaka automaticka konverze kodu P2->P3 je problem ?
Existují nástroje pro konverzi, ale zkonvertovat sémantické změny je obecně problém, který se musí řešit manuálně.
Není to obvykle problém, když se ví co s tím. Např:
from __future__ import print_function
print("Hello World!")
je funkční v Python 2 i 3...
Více třeba zde: https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef
>Zásadním problémem, který zatím nikdo příliš neřeší, je závislost na Pythonu 2 pro různé build skripty programů, které napsané v Pythonu vůbec nejsou.
Mohu potvrdit. S tím bude třeba mít dost zásadní problém macOS.
Tam se v instalačních skriptech může používat cokoliv a Python se používá opravdu velmi často.
Bohužel Apple ve výchozí instalaci dodnes Python 3 vůbec nemá, ani jako alternativu :-(
Na druhou stranu ty instalační sktipty jsou většinou dost jednoduché, takže by mohli být s Pythonem 3 kompatibilní.
No tohle autor článku asi trochu přehnal. Ono datum 1.1.2020 bylo stanoveno jen aby tam nějaké datum svítilo, ale ve skutečnosti to datum není definitivní a nejspíš se zase o pět let posune. Vývojáři jeho podporu ukončit nehodlají, tedy aspoň co jsem zatím četl jejich vyjádření.
Omg, chtit po nem zodkazovat spekulaci je stejny nesmysl jako kdysi, ze 2015 bude definitivni EOL.
AFAIK oficialni termin ke konkretnimu dni nebyl stanoven, odhaduje se duben 2020. Vytykat domenku, ze to bude uz k 1.1. je stejne hloupe jako obhajovat libovolny den v tomto roce.
No honem nenacházím rozhovor nebo konverzaci mezi vývojáři, ale k tomu 1.1.2020 je to v ofiko dokumentaci a tam je to celkem hezky řečené: https://devguide.python.org/#status-of-python-branches
Ten autor mi prijde docela fundamentalisticky -- a zbytecne.
Ten PEP rika
```
It is anticipated that there will eventually come a time where the third party ecosystem surrounding Python 3 is sufficiently mature for this recommendation to be updated to suggest that the python symlink refer to python3 rather than python2.
```
ale soucasne rika i
```
If the Python 2 interpreter becomes uncommon, scripts should nevertheless continue to use the python3 convention rather that just python. This will ease transition in the event that yet another major version of Python is released.
```
Cili ciste teorieticky nic nestoji v ceste tomu, aby python (bez cisla verze), vyhynul nebo byl navzdy spojen s pythonem 2.x. Zjednodusilo by to potom skriptovani.
Bohuzel tato fundamentalisticka preznacovaci manie v distribucich (cimz je jiz ocividne nakazeny i redhat a fedora) ma za nasledek, ze dneska neexistuje python 2.7 shebang, ktery by fungoval vsude -- python je v ArchLinuxu defaultne python3 (navzdory tomuto PEP, ale to muze byt problem soubehu), s python2 mame zase v nasem projektu problemy s MacOS X, protoze ten symlink se standardne nevytvari (a pravdepodobne i nekde jinde, ale ted si nevzpomenu).
> Jsem fundamentalistický.
Ja bych to definoval jako aktivni kokot.
Jinak zbezna prohlidka vaseho verejneho repa na githubu je dost zklamani, same sranda-projekty na urovni krouzku programovani pri zakladni skole. Tyka se jen vlastnich, na forky jsem se nedival.
Celkem to zapada do obvykleho obrazu prumerneho az podprumerneho, ktery se musi hlasiteji ozyvat aby tak kompenzoval nedostatek talentu. Sorry za prikrost..
Nahodou ten clanek dobre upozornuje napriklad na to, aby si lidi prohlidli svoje projekty a treba se konecne dokopali k tomu, aby to prepsali do trojky. Mam pocit, ze presne toto ti vadi (udrzba stareho projektu, kterej se vsichni boji obracet i vidlema?), proto osocujes autora, ktery ma sve tvrzeni skutecne dobre ozdrojovane.
Mate pravdu, Miroslav je pro mne dost velke zklamani.
Jeden by cekal ze v Pythonu 2 uz ani nikdo nedela, ale tady pan autor ma potrebu si neco clankem dokazovat a tancit na hrobu teto ubohe technologie. Typicky obraz prumerneho az podprumerneho aktivniho clena Python komunity, ucitele, a organizatora, ktery se i pres zjevnou nesmyslnost tohoto chovani musi hlasite ozyvat, aby pomohl tem slabsim a pomalejsim s nedostatkem talentu, aby na Python 3 uz konecne presli.
Prosimvas, ani tady o tom radeji nediskutujte. Venujte se necemu uzitecnemu! Kdybyste radeji uklidili odpadky pred domem nebo posbirali nejaka vicka pro deti v krouzku programovani pri zakladni skole.
Sorry za forky, mam poruchu osobnosti.
> python je v ArchLinuxu defaultne python3 (navzdory tomuto PEP, ale to muze byt problem soubehu), s python2 mame zase v nasem projektu problemy s MacOS X, protoze ten symlink se standardne nevytvari (a pravdepodobne i nekde jinde, ale ted si nevzpomenu).
V tomto pripade je najjednoduchsie Arch proste ignorovat, jeho vyvojari a packageri si uz na pustanie sed-u nad pythonimi balickami davno museli zvyknut :)
Tak tohle je buď vaše chyba, že závisíte na nespecifikovaném chování, a nebo chyba specifikace pythonu, že něco naspecifikuje a pak to změní. Já sázím, na první variantu. Bohužel programovat stylem "mě to tu běží" neznamená programovat správně. Nespecifikované (nebo nedefinované) chování je právě určené k tomu, aby mohl kompilátor nebo interpret zvolit rychlejší implementaci, pokud ji někdo vymyslí.
Já jsem zvyklý, že pořadí klíčů ve slovníku může být jiné dokonce při každé iteraci slovníkem. (To vyplývá i z jednoduché implementace slovníku například hashovou tabulkou. Jednoduchá implementace hashové tabulky řeší kolizní klíče spojovým seznamem. Odebrání a přidání klíče pak může tento klíč v tomto seznamu posunout na jiné místo). Dokonce i když vytvoříte dva slovníky stejným způsobem, může mít každý klíče v jiném pořadí. Do hashovací funkce lze totiž přimíchat například adresu slovníku v paměti, právě proto, aby byla menší pravděpodobnost, že dojde k hashovým kolizím právě na stejných klíčích.
Já se nechci hádat, určitě nedoporučuji spoléhat na "ledajaké" implementační detaily -- ale popravdě, většina jede na CPythonu, minimum na PyPy -- které navíc právě se trojkou nepočítá, a pokud píšu interní knihovny a můžu si určit, že jedeme na Pythonu 3.7 a více, tak nevidím problém. Ostatně třeba requests podporují až Python 3.3 (release 2012) a viděl jsem knihovny které mají 3.5+; kvůli čemu myslíte, že nepodporují starší desetinkové verze?
Proc by mel muj kod stale obtizneji upgradovat? Upgradívat pujde porad stejne. Neni duvod, aby ho zahazoval a prehazoval do trojky. Neznas prislovi neopravuj co funguje? Muj klient bez problemu pouziva dokonce i programy pro win16 a to uz je porna historie. Jsou to programy pro cteni dat z jistych mericich serveru. A dokud tyto pobezi, bude pouzivat i tyto programy.
Python 2.5 i Python 2.6 kupříkladu neumožňuje používat TLS 1.2 - ne že by to nešlo v principu, ale ten opruz s předěláním střev za to nestojí. Relativně nedávno to ještě nikoho až tolik netrávilo, ale nepřeju nikomu, aby něco podobého musel řešit u Pythonu 2.7, až bude definitivně zastaralý. Přechod z 2.5 na 2.7 byl legrace, ale dělal jsem ho na jednom systému také za všeobecného pocitu, že 2.5 je pořád v klidu. No, nebyl.
Na tohle se často hodí použít requests místo urllib a nechat SSL/TLS na proxyně. My jsme to tak udělali abychom mohli nechat dožít software běžící ještě na debianu Lenny (10 let stará distribuce), který stahuje něco po https od externího dodavatele (který mezitím přešel na certifikáty, které takhle starý stroj podporovat nikdy nebude). Jako proxy jsme použili Apache, protože ten rozumí proxy požadavku "GET https://foo.bar.baz/url", zatímco Squid (který (z historických důvodů) používáme) protokol 'https' v GETu nepodporuje. Výhoda je, že starý software není potřeba aktualizovat kvůli SSL protože SSL řeší nový software na jiném stroji.
Už jsme chtěli několikrát přejít na python3, ale bohužel tam stále není nic by bylo tak skvělé a zaplatilo by to ten drahý přechod a zpomalení aplikace okolo 20-30%. Pokud se Python3 razantně zrychlí a začnou řešit reálné problémy místo, tak se to možná změní.
Jinak mimochodem to, že je spousta projektů převedená na python3, neznamená, že by se python3 používal, spíše více vývojářů, kteří dělali větší projekty v pythonu odchází, jelikož jim to za to nestojí.