Python 2.7.18, az utolsó Python 2 release

Python 2.7.18 is the last Python 2.7 release and therefore the last Python 2 release. It's time for the CPython community to say a fond but firm farewell to Python 2. Részletek a bejegyzésben.

Hozzászólások

Nem lesz több Python 2 release - mondták és jót nevettek együtt az IBM-mel, a SAPpal, a SUSE val és a Red Hattel.

Akinek szamitott, az mar atallt 3-ra. Akinek nem, annak ugyis mindegy.

En meg orulok, mert nem kell 2-hoz tartozo futtatokornyezetet fenntartani, kodot azzal kompatibilisen tartani (utobbit mondjuk amugy sem tettem, de lib eseten meg lett volna ertelme), es ugy altalaban szivni a 2-es hulyesegei miatt.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Szerintem 2-esre könnyebb támogatni valamit, mint tetszőleges 3.x verzióra (aminél kb. azzal jársz legjobban, ha 2-es kódot írsz).

Egy rakás helyen 3.4-3.5-be futottam bele, aztán megy a csodálkozás a modern python fiatal kóderei által, hogy még az f-string sem működik. :)

Nahát, erről lemaradtam, de totál várható volt. És azt gondolom hasonló lesz a Pythonnal is.

"Raku (formerly known as Perl 6) is a sister language, part of the Perl family, not intended as a replacement for Perl, but as its own thing - libraries exist to allow you to call Perl code from Raku programs and vice versa."

hat amig szinte naponta valtozik a 3-as python szintaxisa, addig nem erdemes nekiallni se a regi kodok portolasanak...

(en azert nekialltam, multkor egy het alatt eleg sok mindent atirtam, raadasul ugy, hogy 2-vel is mukodjon, de eleg favagas/szivas volt es kb semmi ertelme)

>>hat amig szinte naponta valtozik a 3-as python szintaxisa, addig nem erdemes nekiallni se a regi kodok portolasanak...

Miért nem? A szintakszis úgy változik, hogy bővül, nem úgy, hogy valami, ami régen érvényes volt, akkor mától már nem az. Célozd meg például a 3.8-ast, írd a fájl elejére: "#!/usr/bin/env python3.8", és akkor már legalább dokumentálva van a helyzet. Ez persze nem akadályozza meg a "$ python3.6 progi.py" módon történő indítást. Szintaxisbővülés más szkriptnyelveknél is előfordul.

nincs igazad. minden verzioban van csomo "Backwards incompatible syntax changes", nezd csak meg a changelog-okat.

meg vannak deprecation-ok is, ami egyik verzioba meg megy a kovetkezobe mar lehet nem, vagy nem ugy.

hiab airom meg 3.8-al, lehet az 3.6-al nem fog futni, mert abban meg nem volt valami feature implementalva. ha meg 3.6-al tesztelek lehet 3.8-on nem fog futni, mert addigra deprecated lett valami. kb ugyanazt a szopast sikerult elhozniuk a pythonba mint ami a php-ben van 5.x ota.

a libekrol nem is beszelve, pl. az email konyvtarat folyton atvarialjak 3.x ota, es nem csak bovitesrol van szo, hanem ugyanarra az inputra mas outputot ad!

meg a threading mukodeset alapjaiban valtoztattak meg 3.7 korul, es meg sorolhatnam...

en inkabb megvarnam amig elkezdik a 4.x-et fejleszteni, es akkor talan vegre beken hagyjak a 3.x szintaktikajat, ahogy anno a 2.x-el is tortent.

(eleg sok inkompatibilitasba futottam bele anno a 2.3-2.4-2.5 korul, valtozott pl. a strip() szintaxisa is stb)

A'rpi

Ha valóban ennyire hullámzó és kiszámíthatatlan mi jelenik meg és mi tűnik el egy-egy minor verzióban, akkor úgy egészében föl nem foghatom hogy lehet elől a Python a népszerűségi listán. Ezek szerint a Python-ban fejlesztők csak emiatt róják felesleges és meddő köreiket.

Pedig a 7.0 óta szerencsére alig van olyan változtatás benne, ami miatt a korábbi kód ne futna le. Az 5.X-es verziók kb. kiadásonként lőttek le egy csomó 4.X-es érából származó függvényt, majd a 7.0 volt az igazi nagy ágyú, ott kíméletlenül kiirtották a problémás függvényeket. Azóta inkább csak bővült, nagyon ritkán találok olyan kódot, amit 7.0 alatt futott, de 7.3 alatt mondjuk már ne menne.

Az más dolog, hogy még a jövő hónapban is migrálok kódot PHP 5.3 -ról PHP 5.6 alá, szóval gondolom itt sem fog eltűnni a 2.7-es vonal.

Nagy Péter

pont így. és ráadásul egyre hozzánemértőbb emberek (nyelvészek, biológusok) vannak a környékemen, akik büszkén mondják, hogy "jajj el fogok kezdeni programozni! pythonban!"  aha, mondoK, melyikben? és erre csodálkozás. A big data meg a *bányászati szoftverek amiket használni akarnak, többségében 2.x vonalon vannak, nem tudom mit fognak belőle érteni / tudni használni. Nem programozni fognak tudni, hanem belebarbárkodni a 2.x pythonban írt akármi keretrendszerbe...

20+ év programozói tudás után néha ledöbbenek, amikor valami openszorsz python kódot nézek, h tulajdonképp mi a f*szt olvasok? miért jobb ez, mint a c? c++? c#? belépési küszöb nem alacsonyabb, cserébe szarabb a szintaxis és idegesítő kvirkjei vannak, de legalább még saját magával is tud inkompatibilis lenni (és a python által újra feltalált "dll-hell"-ről ne is beszéljünk)

~ubuntu, raspbian, os x~

miért jobb ez, mint a c? c++? c#?

Nekem az volt a tapasztalatom, hogy lényegesen gyorsabban lehetett elkészíteni ugyanazt az algoritmust pythonban (mondjuk amit C++-ban megírtam 2 hónap alatt, azt Pythonban 2 hét alatt)*. Cserébe lényegesen lassabb lett az eredmény és sokkal több memóriát használt.

* a C++ fejlesztési rész ötletelést is tartalmazott, viszont akkor már volt sok év C++ tapasztalatom, a Python megvalósítás egy jó része meg a Python doksi olvasásával telt, mert Python tapasztalatom csak minimális volt.

"miért jobb ez, mint a c? c++? c#? "

Nálunk pl. előfordul egy egy desktopon használt szkript kap online felületet is, persze lehet c, c++kódot is futtatni webszerverrel, de nem tipikus, így meg pont ugyanazokat a könyvtárakat használja mindkét megoldás.

“May have been the losing side. Still not convinced it was the wrong one.”

Huszonévig Windowson is jó volt, hogy jogosultságkezelés nélkül voltak felhasználók, de azért idővel minden fejlődik. :-D

Szerintem amúgy a mai igények mellett már biztonsági szempontból is problémásabb a CGI. Egy esetleges felhasznált külső lib-ben lévő hiba sokszor csak az egész CGI újrafordításával lenne javítható, sokkal nehezebb lenne több száz oldalt futtató szervereket frissíteni.

Nagy Péter

A belépési küszöb alacsonyabb. És ezt pont te támasztod alá az első mondatoddal, hogy akár az egyre hozzánemértőbb emberek is hozányúlnak. A C-nél is a C++-nál főleg. C#-ot nem ismerem, ahhoz nem tudok hozzászólni. A szintaxis megszokás kérdése. Nem tudom, milyen idegesítő kvirkekről beszélsz konkrétum nélkül persze cáfolni sem lehet, legfeljebb majd ha kifejted.

A legtöbben, akik utálják a Pythont, az indentálás miatt utálják, akik viszont használják, rájönnek, hogy az indentálás az egyik legnagyobb előnye a Pythonnak. Minden programnyelvben lehet jól és rosszul olvasható kódot írni, de amíg a C-ben C++-ban viszonylag könnyen meg lehet tenni (talán) mindkettőt - olvashatatlant egyértelműen, Perlben nehéz olvashatót írni, Pythonban meg meglehetősen nehéz olvashatatlan kódot írni. És pont ez az egyik nagy előnye.

Tény, a Python nem támogatja az elitista fejlesztői hozzáállást, és elmossa a határt a komoly fejlesztő és a botcsinálta gányer közt (én is az utóbbihoz sorolom magam egyébként, viszont a munkámhoz teljesen jól - és egyre jobban - tudom használni a minimális Python ismeretemet, amellyel azért elég komoly dolgokat meg tudtam csinálni.

12 év alatt ilyenbe nem futottam még bele, kivéve a Python 3.2re átállás. Mondjuk ahol rajtam múlt, ott 2011re már megtörtént. Most meg küszködnek ezzel sokan, s nem értem. A Python2 azért szimpatikus sokaknak, mert igazából 10 éve is halott nyelv volt, zéró változtatással, kivéve 1 SSL miattit.

>>hiab airom meg 3.8-al, lehet az 3.6-al nem fog futni, mert abban meg nem volt valami feature implementalva.

Ez teljesen rendben van; bővült a szintakszis és a funkcionalitás; e nélkül minden új verzió csak hibajavítás lenne.

Fordítva, hogy egy 3.6-ra írt program szintakszis miatt ne fusson 3.8 alatt, még nem találkoztam.

Ahhoz, hogy egy 3.6-ra írt program azért ne fusson, vagy ne fusson megfelelően, mert 3.8-on az alkalmazott könyvtár másképpen viselkedik, őszintén szólva nem tudok hozzászólni; én még nem akadtam bele, valószínűleg azért, mert eddig elegendő volt csak a "nagyon" standard modulokat használnom.

A fenti verziószámok helyett természetesen mások is behelyettesíthetők, kivéve a 2-es verziót, amit én nem is tekintek Pythonnak:-)

Egyébként meg, ha nem magának fejleszt az ember, akkor az első kérdés az, hogy melyik verzióra kéri az ügyfél, és akkor úgy lesz elkészítve.

> melyik verzióra kéri az ügyfél

sajnos ilyenkor a valasz: mindegyikre IS. :)

csak a most futo/tamogatott ubuntu lts-eken (16-18-20) a python3 verziok: 3.5-3.6-3.8 tehat ezeket minimum kellene tamogatni, meg talan a centos 7-8 pythonjat sem artana...  sot a centos7-en egyszercsak egy sima yum update-tol ugrott a verzio 3.5-rol 3.6-ra, el is multak a kulso forrasbol felrakott modulok hirtelen, csak neztunk mint rozi a moziba.

egyszerubb egyelore a 2.7, az legalabb mindegyiken van a fenteik kozul, es mar ismerjuk az osszes nyugjet-bajat-bugjat :)

szerintem sokan igy vannak meg ezzel, azert nem kene a 2-est temetni... (mondom ezt ugy, hogy vannak a 3-asnak nagyon jo ujitasai, amik miatt szivesen elfelejtenem en is a 2.x-et, de szerintem arra meg nagyon sok evet kell varni)

A'rpi

Hát így már érthető a berzenkedésed. Egyébként az említett  "kulso forrasbol felrakott modulokat" valahová külön kellett volna pakolni, hogy a yum ne találjon rájuk.

Szerk.: A sok verzió kicselezésére jó lenne a virtualenv használata.

nem a yum talalt rajuk, csak a site-packages path valtozott meg a frissites miatt ugye (benne van a python verzioszam). amugy pip3-al lettek felrakva, nem ganyolva. mind1 felraktuk ujra csak fura volt hogy hirtelen miert nem talal meg modulokat...  ubuntuban mexoktam hogy semmi verzioja nem frissul update-kor sose :) meg az se aminek kene (clamav pl).

virtualenv meg nem oldja meg a python verzio kulonbseget szerintem...

persze lehetne mindent virtualizalni, kontenerezni stb, de mivel en foleg rendszer uzemelteteshez irok scripteket, ez ott pont nem nyero.

virtualenv meg nem oldja meg a python verzio kulonbseget szerintem

Be tudod állítani, hogy mi történjen. Alapból csak linkeli a rendszer pythonját, így ha meghagyja azt a csomagkezelő, akkor probléma nélkül működik tovább a venv. De azt is lehet a "--copies" flaggel mindent átmásolsz, így egy teljesen szeparált környezetet kapsz (python bináris szinten is, nem csak a libek esetében).

 

persze lehetne mindent virtualizalni, kontenerezni stb, de mivel en foleg rendszer uzemelteteshez irok scripteket, ez ott pont nem nyero.

Ott _pont_ az lenne a lényeg, hogy garantáltan ne tudja semmi elrontani a környezetet. Ajánlom figyelmedbe a PIPX projektet, amit pont erre találtak ki. Automatikusan létrehoz egy-egy virtuális környezetet minden futtatható paranccsal rendelkező Python programnak, így elkerülöd a dependency-hellt. Automatikusan tudja frissíteni az összes általa felrakott csomagot.

I feel the pain, de szerintem az nettó önszaptás, ha venv nélkül használsz pipet. Tulajdonképp gányolás. Szerintem vagy az van, hogy használod, amit hoz az OS, vagy ha pipelsz, akkor tedd venvbe,  Pipenv egész hasznos tud lenni, poetry is kb ugyanaz pepitában, de egyébként az ansible is tudja kezelni a sima venveket (meg egyébként kézzel se egy nagy tragédia nyilván). Bár a pipenv lockfileos működése sokat segít a reprodukálhatóságon, illetve szigorúan site packages nélküli venv a nyerő, ha lehet, tegye csak fel az egészet ő, ne kelljen kezelni a pippel feltett csomag használ valami verziót a csomagkezelőből kérdéskört.

A venv valóban nem oldja meg a site packagest, azt úgy lehet talán legbolondbiztosabban, ha konkrét alverziós venvet csinálsz. RH vonalon vannak direkt visszaverziózott interpreter csomagok, azzal így viszonylag könnyen megoldható, hogy pontosan az fusson, a csomagokat meg úgyis a pip adja. Talán a debianban is vannak ilyen nem default verziós pythonok, az ubuntuhoz viszont csak valami PPAban ha jól emlékszem.

Bocs, de nekem inkább az jön le a fentiekből, hogy eléggé elavult és önszívató módon próbálsz Pythonban fejleszteni. Ma már minden az izolációról szól, nem véletlenül.

1. Ott a Docker (és hasonló technológiák). Azt a Python verziót használod, amit akarsz, az ügyfél kap egy image-et, minden működik ahogy nálad. Tök mindegy, hogy milyen rendszeren fut.

2. Virtualenv + Poetry csomagkezelő. NPM lockfile-hoz hasonlóan itt is van egy lockfile, amivel reprodukálható csomagkörnyezet hozható létre egy szeparált virtualenv-ben. Egyetlen paranccsal létrejön nulláról az egész egy új rendszeren.

Továbbá tudtommal az async és await kulcsszóvá váláson kívül nem volt más backward incompatible változtatás szintaxisban. Az, hogy van új szintaxis, az nem ez a kategória, mivel pl. 3.6 alá írt kód vígan fut 3.8 alatt is.

 

hiaba irom meg 3.8-al, lehet az 3.6-al nem fog futni, mert abban meg nem volt valami feature implementalva. ha meg 3.6-al tesztelek lehet 3.8-on nem fog futni, mert addigra deprecated lett valami. kb ugyanazt a szopast sikerult elhozniuk a pythonba mint ami a php-ben van 5.x ota.

Ha a "fut-e x Python verzió alatt" kéréskör nem derül a fejlesztés közben az automata tesztek futtatásakor, akkor ott valami baj van. Miért nem állítod be a $kedvenc_automata_tesztelőnek hogy futtassa le a teszteket az összes támogatott Python verzión?

Számomra az volt a két fő előnye, hogy egyrészt nem talált fel egy új fájlformátumot, hanem a PEP-508-ban definiált pyproject.toml fájlt használta, másrészt meg alapból úgy készült, hogy gyors legyen a függőségek feloldása. Már elég régóta használom, rendben teszi a dolgát. A deploy szkriptben van egy lépés, ami kiadja a "poetry install" parancsot a szerveren és feltelepülnek a virtualenv-be az előre meghatározott verziójú csomagok (NPM-hez nagyon hasonlóan).

Bocs, de nekem inkább az jön le a fentiekből, hogy eléggé elavult és önszívató módon próbálsz Pythonban fejleszteni

Bocs, de nekem az jön le a fentiekből, hogy a saját usecased kivetíted mindenki másra.

Ma már minden az izolációról szól, nem véletlenül.

Ha jól emlékszem, valahonnan az akadémiából szabadultál mostanában, tehát gondolom numpyzel, vagy valamelyik neurális hálós izét tolod orrba szájba, vagy egyéb más data crunchinget csinálsz. Ott ez működik, és rém kényelmes. Production szolgáltatást végző rendszerekben is tud, csak ott még ezzel-azzal foglalkozni kell, és csak addig kényelmes, ameddig meg nem kérdezi az üzemeltetés, hogy akkor hogyan vannak garantálva a biztonsági problémákra mondjuk 2 héten belül a javítások? Természetesen venv esetében az összes modulra -- azkora is, amiről kedves fejlesztő jó eséllyel azt se tudod, hogy ott van, mert nem direkt függőség, -- hiszen te szállítottad. Ha konténer, akkor a konténer belsejében levő mindenfélére is leszel kedves ugyanezt, hiszen azokat is. És akkor kiderül, hogy már az sem triviális, hogy egyáltalán meg tudd megmondani, hogy van-e benne ismert vuln.

Továbbá tudtommal az async és await kulcsszóvá váláson kívül nem volt más backward incompatible változtatás szintaxisban. Az, hogy van új szintaxis, az nem ez a kategória, mivel pl. 3.6 alá írt kód vígan fut 3.8 alatt is.

Sajnos ez nem igaz. Bár szerintem anno a 2es ágon is ez volt, mert vannak még nyomai a doksiban, csak már olyan régen 2.7 van, hogy elfelejtette a bagázs, de a hármasban simán az van, hogy valamit deprecatednek jelölnek 3.x-ben, és kidobják 3.x+3ban (fogalmama sincs 3 valódi értékéről). Ráadásul a syntax messze nem minden, és elég sokat basztatják az stdlib darabjait, amire jó eséllyel kevésbé unittesztelsz, szóval fene se tudja, hány edge case romlik meg csendben.

Csak for the fun of it, 3.8 whatsnew doksi, other language changes teteje:

The syntax allowed for keyword names in function calls was further restricted. In particular, f((keyword)=arg) is no longer allowed. It was never intended to permit more than a bare name on the left-hand side of a keyword argument assignment term. (Contributed by Benjamin Peterson in bpo-34641.)

Ez bizony breaking syntax change

When a comma is missed in code such as [(10, 20) (30, 40)], the compiler displays a SyntaxWarning with a helpful suggestion. This improves on just having a TypeError indicating that the first tuple was not callable. (Contributed by Serhiy Storchaka in bpo-15248.)

Valószínűleg nem volt ember, aki ilyesmi miatt except TypeErrort írt, de ha igen, akkor beszopta :)

Arithmetic operations between subclasses of datetime.date or datetime.datetime and datetime.timedelta objects now return an instance of the subclass, rather than the base class. This also affects the return type of operations whose implementation (directly or indirectly) uses datetime.timedelta arithmetic, such as astimezone(). (Contributed by Paul Ganssle in bpo-32417.)

Ugyan ez is jogos, de ha eddig jó volt neked ott a base class, akkor ebből is lehet baj,

Most nem olvasom tovább, de az lejön remélem, hogy azért észnél kell lenni.

Ha jól emlékszem, valahonnan az akadémiából szabadultál mostanában, tehát gondolom numpyzel, vagy valamelyik neurális hálós izét tolod orrba szájba, vagy egyéb más data crunchinget csinálsz. Ott ez működik, és rém kényelmes.

Pont ellenkezőleg, a fentieket egy átlag Python (mondjuk egy Django app, vagy lib) fejlesztésre írtam. A kutatásban attól függ, hogy milyen környezetben dolgozol. Ha nem saját gépparkon, akkor is valszeg a virtualenv a megoldás (feltételezve hogy engedélyezve van) mivel nem lehet a karbantartót kérni hogy rakjon fel ilyen-olyan libet. Ha saját gépparkod van (az én esetemben ez volt) akkor is lehet virtualenvet használni, de én csak egy központi Pythont tartottam karban (libekkel együtt), és minden szimuláció azt használta.

 

ameddig meg nem kérdezi az üzemeltetés, hogy akkor hogyan vannak garantálva a biztonsági problémákra mondjuk 2 héten belül a javítások?

Ezzel azt állítod, hogy az oprendszer Python csomagjait talán jobban karbantartják? Nekem nem ez a tapasztalatom. Manjaro Linuxot használok (rolling release modell) már sok éve, de még egyszer nem jött a 2-3 hetes frissítési ciklusok kívül python csomagra biztonsági frissítés. Ezzel szemben ha fejlesztek valamit, azzal kezdem a napot, hogy megnézem, érkezett-e bármelyik csomaghoz frissítés (poetry run pip list -o). Ha igen, megnézem, hogy mi az. Ezáltal 1-2 nap alatt bekerülhet egy bugjavító kiadás az éles kódba. Meg egyébként is: mi van azokkal a libekkel, amire nincs hivatalos csomag?

 

Természetesen venv esetében az összes modulra -- azkora is, amiről kedves fejlesztő jó eséllyel azt se tudod, hogy ott van, mert nem direkt függőség, -- hiszen te szállítottad.

Ez megint úgy hangzik, mintha 10 évvel ezelőtti problémákról beszélnénk. :) Pontosan tudom, hogy melyik csomagnak mi a függősége, milyen verzión van, stb. Ott van minden a lock-fájlban. Egy egyszerű "poetry run pip list -o" mutatja, ha bárminek van újabb kiadása. 100%-ban ugyanaz települ fel prod. rendszeren, mint a fejlesztői gépen. Azt nem állítom, hogy végignézem rendszeresen az összes lib github/gitab/stb issue-gyűjteményét, hátha talált valaki biztonsági rést, de így még mindig gyorsabban bekerülnek a frissítések az éles kódba, mint a rendszer csomagkezelője által.

Mielőtt a szintaxis változásokba belemennénk egyezzünk meg a terminológiában, mert mintha kétféle értelemben lenne használva a "backward incompatible/breaking syntax change" kifejezés. Szerintem az az "igazán" breaking change, ami megakadályozza a korábbi verziókra írt kód futását az újabb verzión. Ilyen volt az async és await kifejezések kulcsszóvá változtatása. Az szerintem nem breaking change (vagy legalább nem "backward"), hogy új szintaktikai elemet vezetnek be: ne használd és vígan elfut a kód minden Python verzión. A 3.8-as walrus-op meg a positional-only args ilyenek, nem kell használni, ha régebbi Pythont is támogatni kell. A datetime-os változtatás valóban lehet problémás, de egy ilyennek elő kell jönnie tesztelés során.

Szóval nekem még mindig úgy tűnik, hogy olyan problémákat hoztok fel a Python ellen, amik (valamilyen szinten) már meg vannak oldva, csak használni kell a megfelelő eszközt/módszert. Fejlesztek most egy Django/Wagtail kódot, megnéztem: 76 libet rakott fel összesen a Poetry. A fejlesztői gépen 3.8 van, az éles rendszeren még 3.6 fut. Nem használok egyelőre 3.7-8-as szintaktikát benne, így probléma nélkül fut mindenhol. (3.6 alá sosem megyek az f-string miatt).

Ezzel azt állítod, hogy az oprendszer Python csomagjait talán jobban karbantartják?

Azt. Ők sem csinálják túl jól, de nekik vannak válaszaik azokra a kérdésekre, hogy

  • van-e biztonsági probléma a szállított csomagjaikkal?
  • hogyan értesülök erről?
  • fixálva van-e?

Manjaro Linuxot használok (rolling release modell) már sok éve, de még egyszer nem jött a 2-3 hetes frissítési ciklusok kívül python csomagra biztonsági frissítés. Ezzel szemben ha fejlesztek valamit, azzal kezdem a napot, hogy megnézem, érkezett-e bármelyik csomaghoz frissítés (poetry run pip list -o).  

Ne keverd a csomag security updatejeit a csomag frissességével. 

Ezzel szemben ha fejlesztek valamit, azzal kezdem a napot, hogy megnézem, érkezett-e bármelyik csomaghoz frissítés (poetry run pip list -o).  

Akkor jó úton jársz, te vagy az ezerből az egy fejlesztő. Bár azt azért finoman kétlem, hogy valóban a munkafolyamataid részét képezi, hogy ha kiadtál a kezedből valamit, akkor annak a következő 2-3 évben minden reggel nézegeted a függőségeit. Őszintén szólva még abban is kételkedek egy kicsit, hogy amin éppen dolgozol, azzal valóban ezt csinálod. Van némi fogalmam arról, mi lenne, ha egy csapatban minden reggel valaki commitolna egy új lock filet. (és igen, persze, lehet automatizálni)

Meg egyébként is: mi van azokkal a libekkel, amire nincs hivatalos csomag?

Hát ez az :)

Ez megint úgy hangzik, mintha 10 évvel ezelőtti problémákról beszélnénk. :)

Nézd, a munkám egy viszonylag jelentős része, hogy python fejlesztő is vagyok. Egészen képben vagyok azzal, hogyan működik az ökoszisztéma, mi van docker fronton, mi van CI fronton, mert ezeket mi is használjuk, és igyekszünk jól csinálni. Szóval nem, ez pontosan úgy hangzik, mint amikor átlag fejlesztő nem érti az üzemeltetési igényeket.

Pontosan tudom, hogy melyik csomagnak mi a függősége, milyen verzión van, stb. Ott van minden a lock-fájlban. Egy egyszerű "poetry run pip list -o" mutatja, ha bárminek van újabb kiadása. 100%-ban ugyanaz települ fel prod. rendszeren, mint a fejlesztői gépen. Azt nem állítom, hogy végignézem rendszeresen az összes lib github/gitab/stb issue-gyűjteményét, hátha talált valaki biztonsági rést, de így még mindig gyorsabban bekerülnek a frissítések az éles kódba, mint a rendszer csomagkezelője által.

Pontosan tudom, mi van egy lock fileban. És pontosan arról van szó, hogy az üzemeltető, akit meg egyébként kötnek pl a security requirementjei (amit meg időnként mindenféle jogszabályok kötnek) bizony a fenti kérdéseket fel fogja tenni. Szóval a  "Azt nem állítom, hogy végignézem rendszeresen az összes lib github/gitab/stb issue-gyűjteményét," az válasznak kevés lesz. Ha te akarod szállítani, akkor bizony neked ezt csinálni kell. Tudnod kell róla, ha baj van. Jelezned kell róla, ha baj van. Vállalásokat kell tenned arra nézvést, hogy mennyi idő alatt oldod meg a problémát. Arról a finomságról pedig -- szokásosan -- nem vettél tudomást, hogy ha konténereket szállítasz, akkor nem csak a python kódoddal kell ezt tenned. Hanem pl ha adod az nginxes konténert a djangod mellé, akkor azzal is kell foglalkoznod. Meg az általa használt opensslel is. Ha több konténert szállítasz, akkor mindben.

Mielőtt a szintaxis változásokba belemennénk egyezzünk meg a terminológiában, mert mintha kétféle értelemben lenne használva a "backward incompatible/breaking syntax change" kifejezés. Szerintem az az "igazán" breaking change, ami megakadályozza a korábbi verziókra írt kód futását az újabb verzión. Ilyen volt az async és await kifejezések kulcsszóvá változtatása. Az szerintem nem breaking change (vagy legalább nem "backward"), hogy új szintaktikai elemet vezetnek be: ne használd és vígan elfut a kód minden Python verzión. A 3.8-as walrus-op meg a positional-only args ilyenek, nem kell használni, ha régebbi Pythont is támogatni kell. A datetime-os változtatás valóban lehet problémás, de egy ilyennek elő kell jönnie tesztelés során.

Nem lett, a breaking syntax changen azt értem amit te. n+1 python verzión SyntaxErrort dobva meg fog állni. Az első idézett példa " In particular, f((keyword)=arg) is no longer allowed. " pontosan ilyen. És ezt simán csak az utolsó release noteba belenézve.

A többiről pedig direkt írtam, hogy a syntax change nem minden, egy duck typing / dinamikusan típusos, interpertált nyelvnél az stdlibben megváltozott viselkedések konkrét unit teszt híján simán át tudnak csúszni. Persze, lehet jól unittesztelni, meg lehet ellenőrizni type annotációkat, meg minden félét, ráadásul tényleg fájdalmasat azért szerintem viszonylag ritkán törnek, de igen is az van, hogy ezekkel kell foglalkozni, nem az van, hogy "jó, az asyncet kulcsszavasították, de egyébként nem törik semmi upgradekor). A konkrét példák mindegyek, csak idézgettem az utolsó release notesból, amire rápillantva simán lehet baj, és nem nagyon kellett erőlködni, hogy találjak.

Szóval nekem még mindig úgy tűnik, hogy olyan problémákat hoztok fel a Python ellen, amik (valamilyen szinten) már meg vannak oldva, csak használni kell a megfelelő eszközt/módszert.

Nézd, én szeretem a pythont, szerintem egy tök jó eszköz. De egyrészt tisztában kell vele lenni, hogy vannak hülyeségei, másrészt meg te kezdted a kissé lekezelő "hát csak be kell dobni egy venvbe/konténerbe és kész is, nem értesz hozzá" dumát, én pedig szerettem volna felhívni a figyelmedet rá, hogy az a "csak" az időnként egy nagyon költséges "csak", és nem mindig jó megoldás, leginkább azért megy minden az izoláció felé, mert akkor nem kell a fejlesztő úrnak azon gondolkodni, hogy "mi van azokkal a csomagokkal, amik nincsenek".

Sikerült kiragadnod a lényeget :) Annó megnéztem, nyilván fehér ember ilyet le nem ír, de ettől még breaking syntax change, szóval ha már a lendületből felütött doksiban benne volt, betettem, hogy de.

De igazából a nagyobb bajok azok az ilyen gyönyszemek:

Starting with Python 3.3, importing ABCs from collections was deprecated, and importing should be done from collections.abc. Being able to import from collections was marked for removal in 3.8, but has been delayed to 3.9.

 Ez tipikusan olyan, amit simán csináltál és ha nem figyelsz, el fog törni a szoftvered a francba. Nyilván van deprecation warning, de ettől még simogatást igényel.

A tények, azok tények, el kell ismernem. De bizonyára van ilyen más szkriptnyelveknél is, vagy nem? Jó, talán a BASH-nál nincs, de az még a kőkorszak:-)  És egyébként is elég hosszú kifutási időt hagytak: Python 3.3.0 2012 , Python 3.9 2020, azaz 8 év. És minden kiadás doksijában ott van a figyelmeztetés.

A Python 2 egy másik nyelv. A fejlesztők rájöttek, hogy vannak benne nem logikusan kivitelezett dolgok, amiket a 2-es verzió toldozásával nem lehetett volna úgy kijavítani, hogy a kompatibilitás fennmaradjon; ezért álltak neki a 3-as verziónak, ahol tiszta lappal indulhattak. Amit lehetett, azt azért átvették a 2-esből.

Miért nem állítod be a $kedvenc_automata_tesztelőnek hogy futtassa le a teszteket az összes támogatott Python verzión?

Ezt a még meg sem jelentetett verziókkal hogyan kéne csinálni? Nyilvánvalóan alapelvárás lenne, hogy ha megírom a scriptet, amikor a 3.6 a létező legfrissebb, akkor ha később alatta az OS-t frissítik, és jön a 3.7, meg a 3.8, meg a 3.9, akkor egy ilyen frissítéstől ne törjön el a script. Ha minden egyes szaros új verziónál végig kell tesztelni (mert LESZNEK eltörő dolgok, ergó lesznek fixálandó dolgok), akkor ott ette meg a fene az egészet.

akkor egy ilyen frissítéstől ne törjön el a script

Erre van kitalálva a virtualenv. Ha a szkripted egy venvben csücsül, ahova át van másolva a neki megfelelő környezet, akkor nem lesz gond frissítéskor sem (feltéve, hogy nem változott annyit az alaprendszer, hogy a régebbi python ne fusson). De én nem hiszek abban, hogy egy komplex szkriptet meg lehet úgy írni egy nem halott nyelven, hogy soha többé ne kelljen hozzányúlni. Vagy ne frissítsd alatta sosem a rendszert és működni fog örökké, vagy fogadd el, hogy ha változik a környezet, akkor néha változtatni kell a szkripten is.

Én inkább arra szavazok, hogy fejlődjön a nyelv. Lehet eddig szerencsém volt, de nem is emlékszek olyanra, hogy 3.x ágon bármiért is frissítenem kellett volna a Python kódjaimat. (2.7->3.x átállásnál akadt pár természetesen.)

Erre van kitalálva a virtualenv. Ha a szkripted egy venvben csücsül, ahova át van másolva a neki megfelelő környezet, akkor nem lesz gond frissítéskor sem (feltéve, hogy nem változott annyit az alaprendszer, hogy a régebbi python ne fusson).

Hát de ez nem tud semmivel sem többet, mint egy docker konténer.

Erre sok helyen azt a megoldast lattam (es mi is elkezdtuk hasznalni), hogy a python cuccoddal szallitod a virtualenv-et is, amiben ott van az osszes fuggosege. A vagrant pl. pont ugyanezt csinalja ruby-val es rvm-mel. Csinalsz egy virtualenv-et, pip install -r requirements.txt, es a teljes virtualenvet becsomagoljuk rpm/deb-be. Igy nem erint a python verzio valtozas. Olyan moduloknal is segit, aminek van C szintu fuggosege, mint pl a legtobb db connector. Hasonlo, mintha egy docker containert adnal, csak kicsiben, azt altalaban el szoktak fogadni, hogy a "myfantasitcutil" parancshoz fel kell tenni egy csomagot.

Koveted az upstreamet, ezt ezzel nem lehet meguszni, ugyanugy, mint akkor tenned, ha a system pythont hasznalod, ebbol a szempontbol semmi nem mas. Azt lehet meguszni vele, hogy nem elesben fogja eltorni, ha pl python verzio upgrade van dist upgradelnel, hanem a legkozelebbi buildkor, es nem stresszhelyzetben kell megjavitani.