Názory k článku Python 3.15 přináší líné importy, neměnný slovník a experimentální JIT

je to jen pocit, nebo se opravdu Python takto "rozjel" po odchodu Guida? Tedy zrovna to rozbalování seznamů atd. v list comprehension je takové už trošku Perlovsky komplexní, no zase proč ne nakonec.

To je mile ze tu mame verziu 3.15 ale stale skoro vsetci programuju na 3.12 :-)

Jako že udržují kompatibilitu s 3.12, nebo skutečně běží interpret 3.12? Popravdě se mi to moc nezdá, protože i distra přechází na 3.13/3.14 (3.12 už neopravuje bugy, jen CVEčka).

U nas je to aj firemna politika a tak sa pouziva aj interpreter 3.12 ale co viem od kolegov tak pouzivaju maximalne 3.13. Inak len tak pre zaujimavost macOS dodnes spolu z XCode instaluje Python 3.9

na našem projektu oficiálně podporujeme 3.12-3.14 (a 3.15 zkusím ASAP), ale řekl bych, že většina develů už má 3.14 a ta 3.12 se jen testuje na CI. Takže vlastně ano, ty novinky v 3.14+3.15, které rozšiřují jazyk se vlastně nevyužívají. Proto je taky projekt plný starých konstrukcí a pár pravidel linterů je explicitně zakázáno, pravě kvůli podpoře staršího Pythonu.

Ale 3.9 je už dokonce mimo CVE fixy, to by nám asi rychle někdo omlátil o hlavu .-)

V LTS Ubuntu 22.04 je Python 3.10. Záleží pochopitelně na projektu, ale požadavek na jeho běh na doposud podporovaném OS může být zcela legitimní.

Já třeba v jednom projektu donedávna měl závislost na knihovně, která funguje jen v 3.11. Pro 3.12 bych musel nasadit patch, který je na GitHubu v seznamu pull requestů ve frontě. Vývoj ale už umřel. Nakonec se ten projekt z většiny zahodil a udělal se odznova, jinak, ale s principy z mé verze.

Přesně tak, takt bych tohle rozlišoval.

Osobně mám většinou nějakou rozumně podporovanou/ak­tuální verzi interpretru podle platformy, což může být docela rozpětí verzí.
Když jsou to kontejnery, tak si samozřejmě můžu vybrat víceméně, co chci. Ale pokud jsou to nějaké systémové skripty, většinou se snažím zůstat u toho, co je standardně v dané distribuci (nebo výchozí ve FreeBSD portech, což je třeba teď 3.12).

Ale přes to všechno krom nějakých pokusů mám víceméně všechno napsané s vlastnostmi jazyka a std. knihovny, co odpovídá 3.8 (což byla třeba dlouhou dobu poslední verze v RHEL/CentOS 7 přes SCL).
Asi jsem sto let za opicema, ale kdybych chtěl, mohu z fauny aspoň používat mrože :) nebo f-stringy. Taky to snižuje kognitivní zátěž, když člověk přechází nebo dopisuje věci do starších projektů a nemusí pořád mentálně přepínat mezi různými způsoby zápisu té samé věci.
Ale zrovna minulý týden po dokončení nějakého projektu jsem se na to díval a říkal si, jak a jestli to případně refaktorovat s použitím vlastností nových verzí, co by to přineslo (možná i nějaké ušetření externích modulů, přidání type hintů, kde jsem to neřešil), jak by mi mohl pomoc nějaký AI agent (který tedy ve většině případů bez dalších instrukcí právě používá všechno, co nabízí poslední verze jazyka) atp.
Nemám úplně přehled, jak to řeší ostatní, ale asi bych také čekal, že to spíš bude podobné "převalování" jednou za čas (roky), než že by viseli na každém novém PEP a hned to zkoušeli uplatnit.

Každopádně moc díky za vaše články s přehledy.

Data jsou tady: https://git.afpy.org/mdk/python-versions

tak proti tvrdým datům nelze nic říct. Jako ale je to zvláštní, když 3.13 a 3.14 jsou (když už nic jiného) o dost rychlejší. Možná tedy není pro mnoho účelů pomalost Pythonu až takový problém...

JJ, diví se tomu spousta lidí. Podle někoho jde o vyzrálost knihoven.

Je pravda ze od Pythona asi nikto rychlost neocakava, myslim ze ma ine prednosti. Ale Python je na tom este stale lepsie ako Java tam sa pouzivaju verzie co poznali dinosaurov :-)

3.13 prislo s novym threading modelom a kniznice s nativnymi modulmi s tym mali problem. Chvilu im trvalo, kym sa prisposobili, aj to nie vsetky, boli nejake straty.

Ano, pouzivatelia sa tomu mohli vyhnut s 3.13 vs 3.13t, ale to je zase dalsia plechovka cervikov a stale nemuseli mat svoje moduly.

To JIT ale aktuálně bylo (nebo brzy bude) z vývojové verze Pythonu vykopnuto a jeho budoucnost je značně nejistá, ne?

Velmi si cením těchto úzce zaměřených článků.

Jen mě mrzí, že tyhle webovky neobarvují kód. Asi nikdo z nás neprogramuje v editoru, kde by text byl jednobarevný, prostě to nedává smysl. Stejně to vidím tady. Autoři si dali spoustu práce s články a čitelnost zdrojových kódů dost pokulhává, protože jsou jen černé na bílém.

Nevím kdo to má v moci, ale můžete prosím použít jednu z mnoha open source knihoven na obarvení zdrojových kódů? Děkuji

root.cz používá redakční systém Internet infa a myslím, že redaktoři by rádi, ale není to v jejich kompetenci.

tampermonkey + Claude code:
https://ibb.co/gLmsDbqd

(Tampermonkey je doplnok prehliadača. Claude vytvorí user script, ktorý to vyfarbí. User scripty treba zvlášť povoliť.)