Python 2 kódok nélkül érkezhet a Bullseye és a Focal Fossa

Debian

Erőfeszítések folynak, hogy a közelgő kiadású Ubuntu 20.04 LTS (kódnevén: "Focal Fossa") és a Debian GNU/Linux 11 "Bullseye" operációs rendszerek Python 2 kódok nélkül érkeznek. Sok ismert biztonsági kockázatot rejtő Python 2 kódú alkalmazás található a háttértárolóik csomagjaban. A két disztribúció fejlesztői együttműködve távolítják el az olyan programokat, melyek nem kerültek átírásra Python 3-ra.

A néhány éve már folyamatban lévő áttérés Python 2-ről Python 3-ra nem minden csomag esetében valósult meg, így azokat a kódokat, melyek még Python 2-ben maradtak, helyettesítéssel igyekeznek pótolni.
Az Ubuntu és a Debian fejlesztői nemrégiben tájékoztatták a csomagkarbantartókat, hogyan gyorsíthatják meg a Python 2 programokat tartalmazó csomagok eltávolításának folyamatát, mert közeleg az Ubuntu 20.04 LTS (Focal Fossa) és a Debian GNU/Linux 11 "Bullseye" kiadása.

A legfrissebb statisztikák szerint a Debian projekt már lezárta a Python 2 eltávolításával kapcsolatos 3300 bejelentett hiba felét a Debian GNU/Linux 11 "Bullseye" disztribúcióban, 350 Python 2 csomag csak már az Ubuntu 20.04 LTS-ben (Focal Fossa) érhető el. Jelenleg mindkét közösség figyelmezteti a csomagmegőrzőket, hogy összpontosítsanak a nem áttelepíthető csomagokra és számuk csökkentésére.

Magának a Python 2 kódjának Python 3-ra átállásról több dokumentáció és tutorial is fellelhető; maga a Python is rendelkezik kész megoldással, de ahhoz, hogy a teljes átállás megtörténjen, a csomagokat is újra el kell készíteni, hogy azok már a Python 3-as kódolással készült alkalmazásokat tartalmazzák.

További részletek itt olvashatók.

( mt9 | 2019. 11. 14., cs – 20:58 )

Szerkesztve: 2019. 11. 14., cs – 20:58

Tekintve, hogy már 3.8-nál járunk, és "csak" 10 év volt átállni, baj ez? 

Nyilván. Kérdés, hogy van-e ezekre szükség? Nyilván ha 10 év alatt senkinek se hiányzott annyira, hogy naprakészen tartsa a kódot, se az eredeti készítőnek, se valakinek, aki forkolná, akkor lehet érdemes elengedni. Ha pedig nem, akkor érdemes lehet valakinek felkapni, és frissíteni. Nincs ezzel baj. 

sokaig huztam en is a kodjaim/scriptjeim upgradejet de nyaron vegul megleptem. nem volt olyan veszes mint vartam, es sokminden letisztultabb is lett, a py3 azert sokkal atgondoltabb, nem akkora katyvasz mint a 2.x volt.

a legnagyobb melo idoben a print-ek zarojelesitese es a tab-ok space-re cserelese, de mind2 eleg jol automatizalhato akar egy python scripttel :)

> Erre mint ha hivatalos toolok is lettek volna annó.

Van:

$ py -3 -m lib2to3 --help
Usage: 2to3 [options] file|dir …

$ py -3 -m lib2to3 -w .
RefactoringTool: Skipping optional fixer: buffer
RefactoringTool: Skipping optional fixer: idioms
RefactoringTool: Skipping optional fixer: set_literal
RefactoringTool: Skipping optional fixer: ws_comma
RefactoringTool: Refactored .\test.py
--- .\test.py   (original)
+++ .\test.py   (refactored)
@@ -1 +1 @@
-print "hello"
+print("hello")
RefactoringTool: Files that were modified:
RefactoringTool: .\test.py

Nekem amúgy kényelmesebb/átláthatóbb volt a zárójel nélküli print, de megértem a változtatás okát.

Meg az iterator-okra cserélt dolgok miatt is sokszor növekszik a line noise:

>>> a = {"hello": 1}
>>> a.keys()[0]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'dict_keys' object does not support indexing
>>> list(a.keys())[0]
'hello'

Szerintem jóval gyorsabb lett volna az átállás, ha ráfekszenek a performanciára/JIT-re. 

Na megküzdöttem ezzel is.
- mixed tab & space kilőve .. tisztán 8 space legyen tab helyett. vim set expandtab :retab és megoldva.
- print --> print() kell a zárójel
- iterátor: def next() --> def __next__()
- xrange --> range

Működik az új kód, PyPy3 is szépen viszi. A boldogságom nem határtalan a futásidőket elnézve.

$ time pypy ./adatfeldolgozo-2.7.py | wc -l
12154552

real    8m41,559s
user    8m24,787s
sys    1m0,037s

$ time pypy3 ./adatfeldolgozo-3.py | wc -l
12154552

real    14m10,641s
user    13m44,228s
sys    1m16,129s

time python3 ./adatfeldolgozo-3.py | wc -l
12154552

real    21m53,669s
user    22m7,865s
sys    0m55,524s
 

nekem nem tunt fel erezheto sebessegkulonbseg eddig, de most mertem egyet:

Python 2.7.12 (default, Oct  8 2019, 14:14:10)

real    9m28.515s
user    9m22.984s
sys    0m5.132s

 

Python 3.5.2 (default, Oct  8 2019, 13:06:37)

real    5m21.760s
user    5m16.272s
sys    0m5.048s

szoval nalam a 3-as gyorsabban futott.

na kigyomlaltam belole a htmlparser es html2text fuggosegeket (ami minimal kell belole azt kivaltottam par regexp-el), igy:

Python 2.7.12   9m27.712s

Python 3.5.2:    5m11.973s

Python 3.6.8:    8m51.226s

pypy2:              5m20.859s

pypy3.6-v7.2.0 (Python 3.6.9):  11m12.007s  ???   ezt lefuttattam meg 2x, a legjobb ido is 11m04 szoval valami nem koser ezzel a pypy3-al meg

pypy3-v5.10.1 (Python 3.5.3):    6m35.267s

pypy3-v6.0.0  (Python 3.5.3):    6m46.008s