NCSC waarschuwt voor einde ondersteuning Python 2

De National Cyber Security Centres van Nederland en het Verenigd Koninkrijk waarschuwen ontwikkelaars die nog Python 2 gebruiken ervoor dat ze moeten overstappen naar Python 3. Op 1 januari 2020 stopt de ondersteuning voor Python 2.

Het stoppen van de ondersteuning betekent dat Python 2 vanaf 1 januari volgend jaar geen beveiligingsupdates meer krijgt. Het Nederlandse NCSC adviseert ontwikkelaars zo snel mogelijk over te stappen op Python 3. Het Centrum verwijst hen voor verdere toelichting door naar een blog van hun Britse evenknie, en naar een eigen factsheet over end-of-life-procedures voor software.

Uit statistieken van de Python Package Index blijkt dat in ieder geval in juni 2019 het gros van de downloads nog packages voor Python 2.x-versies waren. Het gaat om miljoenen downloads per maand voor een versie die vanaf 1 januari als onveilig te beschouwen is.

De Britse NCSC waarschuwt ontwikkelaars dat ze hiermee hun organisaties risico laten lopen en functionaliteit van Python 3 mislopen. Het beveiligingscentrum wijst ontwikkelaars die willen overstappen door naar tools die daarbij kunnen helpen, zoals Can I Use Python 3 dat projecten analyseert op mogelijke problemen die kunnen ontstaan.

Package	Python 2	Python 3	Versie onbekend
Colorama	82.07%	17.71%	0.22%
botocore	72.86%	26.84%	0.30%
urllib3	64.14%	35.50%	0.37%
Requests	53.37%	46.02%	0.61%
scikit-learn	43.80%	55.90%	0.30%
NumPy	40.69%	58.70%	0.61%
Pillow	37.78%	61.31%	0.91%
TensorFlow	37.66%	61.25%	1.09%
Matplotlib	33.17%	66.34%	0.49%
Flask	31.28%	68.33%	0.39%

Reacties (39)

[Jorgen]

Goed dat er pro-actief gewaarschuwd wordt. Waar vooral de gebruikers en opdrachtgevers / het management geen idee hebben van de techniek erachter, kunnen programmeurs en systeembeheerders zo ook beter duidelijk maken waarom er nieuwe investering qua tijd en geld nodig is om de systemen weer veilig en up to date te krijgen.

[Reactie gewijzigd door Jorgen op 23 juli 2024 04:19]

[RoestVrijStaal]

Van de andere kant valt ontwikkelaars van Python te verwijten dat ze minimaal 3 backwards compability breaks die grote impact hebben in versie 3 hebben gegooid. Waardoor het werk voor te migreren naar Python 3 bijna evenveel is als de applicatie opnieuw schrijven in een andere programmeertaal waarvan de ontwikkelaars niet dit soort fratsen uithalen.

Maar gelukkig is migreren niet de enige optie, er is al een community-fork van Python2 of het wordt PyPy gebruiken.

[psyBSD]

Python 3 is 11 jaar oud, oké in de begin jaren was de api-stabiliteit een dingetje, maar vanaf 3.3 is het alleen maar beter geworden, met nieuwe features zonder backwards compatibility te breken.

En Python 3.3 is al 7 jaar oud... Lijkt me dat je ruim de tijd hebt gehad om wat te doen om je continuïteit te waarborgen.

[deadinspace]

... minimaal 3 backwards compability breaks die grote impact hebben in versie 3 hebben gegooid. Waardoor het werk voor te migreren naar Python 3 bijna evenveel is als de applicatie opnieuw schrijven in een andere programmeertaal ...

Nou nou nou...

Python 2 en Python 3 zijn in grote lijnen dezelfde taal. Ja, er zijn een aantal belangrijke verschillen, maar je project "herschrijven" van Python 2 naar een taal die 90% hetzelfde is is gigantisch veel minder werk dan herschrijven naar een compleet andere taal.

Er zijn zelfs tools die daarmee kunnen helpen, en meerdere libraries die helpen om een project op zowel Python 2 als Python 3 te laten werken.

... een andere programmeertaal waarvan de ontwikkelaars niet dit soort fratsen uithalen.

De taal verbeteren (vergis je niet, Python 3 is duidelijk een betere taal dan Python 2) zijn "fratsen"?

Vergeet daarbij niet dat Python 3 al meer dan 10 jaar oud is, en dat de EOL van Python 2 al in 2012 bekend gemaakt is (en in 2014 is verschoven naar januari 2020). Ja, een backwards incompatible major release is pijnlijk, maar het is niet alsof ze dit gisteren even over de schutting gegooid hebben.

[Reactie gewijzigd door deadinspace op 23 juli 2024 04:19]

[gekkie]

Wel benieuwd wat jouw top-3 van backwards incompatible changes dan is waardoor je hele applicaties (handmatig) opnieuw moet gaan schrijven.

[zonoskar]

print(string) ipv print string

[Yankovic]

Een dergelijke change zou zeer veilig door te voeren moeten zijn.
Namelijk replace ^print (.*)$ met print($1) (mogelijk iets versimpeld bij multilines e.d. maar dat is ook wel te fixen)

Daarbij, als je een applicatie hebt die zo enorm groot is dat je voor 2020 niet meer op tijd kan upgraden was het sowieso al verstandiger geweest om de logging module te gebruiken en heb je al reden genoeg om er tijd aan te besteden :-)

[bwerg]

Namelijk replace ^print (.*)$ met print($1)

Zullen we dat gewoon even op het niveau van de AST/grammatica doen, in plaats van met een regex die ook inhoud van strings kan verneuken? Nooit regexen gaan gebruiken om expressies te zoeken/vervangen in een taal die niet regulier is, als je een beetje waarde hecht aan kwaliteit.

[supersnathan94]

Nouja. Voor een print statement vind ik het nou niet heel gevaarlijk. In principe zou je dergelijke output willen unittesten als het zo belangrijk is. En dan kun je dit dus wel degelijk doen.

[deadinspace]

Zijn regular expression mist print statements met leading whitespace (indentation).

Zijn regular expression mist print statements zonder spaties van de vorm print(1,2) (wat in Python 2 dus een tuple print).

Zijn regular expression matcht ook binnen strings (zoals bwerg al aanhaalde). Het verprutst bijvoorbeeld de volgende string literal tot aan een syntax error toe:

"""
...
This function collects all the open revisions, finalizes them, and will then
print the document."""

Zijn regular expression gaat niet goed om met print statements van de vorm print "hoi", (trailing comma).

Zijn regular expression gaat al helemaal niet goed om met print >> sys.stderr, "hoi"

Nee, bwerg heeft gewoon gelijk; regular expressions zijn gewoon een slechte oplossing hiervoor. Die vertaling dient gewoon op AST-niveau te gebeuren. En er zijn ook gewoon tools die dat voor je doen, dus er is geen reden om dat zelf te gaan lopen search & replacen.

[Reactie gewijzigd door deadinspace op 23 juli 2024 04:19]

[supersnathan94]

Ja dat zal best maar als je een project hebt voor werk wat alle verschillende mogelijkheden voor een print gebruikt, dan zou ik sowieso eerst teruggaan naar de tekentafel. Daarnaast is het op een forum natuurlijk niet zo dat je heel veel moeite gaat steken om hier een perfecte regex neer te zetten.

Kijk uiteraard laat je het liever aan een geteste Library over, maar dat betekent niet dat het met regex replace voor kleine scriptjes niet kan.

[deadinspace]

Ja dat zal best maar als je een project hebt voor werk wat alle verschillende mogelijkheden voor een print gebruikt, dan zou ik sowieso eerst teruggaan naar de tekentafel.

Het is voor een command-line tool niet ongebruikelijk om op dezelfde regel een dynamische voortgang weer te geven op stderr. Zoiets bijvoorbeeld:

for percentage in range(101):
      print >> sys.stderr, '\rprogress: {}%'.format(percentage),

Deze ene print statement (die totaal niet onredelijk is) gaat al mis met de genoemde regexp op 3 van de 5 punten die ik aanhaalde.

Je opmerking over "terug naar de tekentafel" slaat dan ook nergens op, zeker niet voor grotere projecten.

Daarnaast is het op een forum natuurlijk niet zo dat je heel veel moeite gaat steken om hier een perfecte regex neer te zetten.

Het punt is nu net dat een perfecte regexp niet bestaat.

Reguliere expressies zijn beperkt in wat ze kunnen parsen tot reguliere talen. Python is, net als vrijwel elke andere programmeertaal, geen reguliere taal, wat regexps gewoon ongeschikt gereedschap hiervoor maakt. Voor elke regexp valt een Python programma te verzinnen waar de regexp op faalt.

Natuurlijk, met genoeg moeite kun je vast een regexp schrijven die meer dan 99% van de gevallen correct afhandelt, maar het is zinloos om die moeite te doen als er al software bestaat die het in 100% van de gevallen correct afhandelt.

[Reactie gewijzigd door deadinspace op 23 juli 2024 04:19]

[TheVivaldi]

"Daarbij, als je een applicatie hebt die zo enorm groot is dat je voor 2020 niet meer op tijd kan upgraden was het sowieso al verstandiger geweest om de logging module te gebruiken en heb je al reden genoeg om er tijd aan te besteden :-)"

Of om eerder te beginnen met herschrijven. Immers, Python 3 is inmiddels alweer een aantal jaar op de markt.

[RoestVrijStaal]

Als je op Wikipedia kijkt, heb je er al een aantal zorgelijke te pakken:

1. print, en de discussie door andere tweakers erover laat zien dat het niet een simpele string-replace is. Maar dat men naar de context moet kijken alvorens het te refactoren.

2. Het verwijderen van input en ter gelijker tijd raw_input hernoemen naar input.
Hoe, hoe, hoe komen ze erop dat dit een goed idee is?
Als ze input verwijderen, waren ze er ook al.
Nu moeten dus gerefactord worden op de plekken waar èn input gebruikt is èn waar raw_input gebruikt is. In die situatie konden ze in Python4 of Python5 raw_input hernoemen naar input. Maar door het in één major release te doen maakt deze wijziging refactoring niet gemakkelijk.

3. Als in Python2 de rekensom 5 / 2 een 2 oplevert, en opeens in Python3 een 2.5, levert dat meer edge cases op. En -je verwacht het niet- de tests moeten dus worden uitgebreid om de code te testen op die edge cases, ALS die testen er al zijn.

Edit: Hoezo werken de mono- en code-bb-codes niet op FP?

[Reactie gewijzigd door RoestVrijStaal op 23 juli 2024 04:19]

[gekkie]

Hmm ik ben toch maar matig onder de indruk van jouw top3 als ondersteuning van je veronderstelling dat een rewrite in een andere taal sneller danwel minder werk zou zijn.

Punt 1 en 2 had je (als je er al zo intensief gebruik van maakt) prima gedurende die tig jaar in python2 gaande weg kunnen oplossen (from future).

3. Is opletten, maar ook hier is de kans al groot dat je eigenlijk 2.5 al uitkomst wilde hebben en dat al als zodanig geimplementeerd hebt (en dat zou moeten blijven werken).

Enuhmm mono was tweakers2, dit is tweakers3 ... niet backwards compatible

[webkiller71]

Dat is toch het idee van een major version? Dat je breaking changes kan doen. Het is wel zo dat ze de migratie niet zo makkelijk maakten door bijvoorbeeld unicode literals niet toe te staan maar vanaf Python 3.3 was dat gelukkig toegestaan.

[burne]

Wacht maar tot ‘ie hoort wat ze allemaal gedaan hebben in Perl 6...

[gekkie]

Bij python duurde het wel een tijd voor er wat tractie kwam om van 2 naar 3 te gaan, maar bij perl zie ik het nog wel helemaal stagneren.

[RoestVrijStaal]

Ja, maar er is een verschil tussen het behapbaar houden voor je userbase.

Niet alle kritische wijzigingen hadden in één major release gemoeten. Ze hadden het ook kunnen spreiden naar 3 à 4 major releases.
Op zo'n manier wordt de queeste om van de oude situatie naar de nieuwe situatie te gaan niet zo'n dikke bittere pil.

[ro4sho]

Het gebruiken van die forks lijkt me nou juist niet de juiste weg.

[RoestVrijStaal]

En waarom dan wel niet?

Als een open source project om watvoor reden niet geforkt kan worden, duidt dat op "vendor-lockin".

[ro4sho]

Ik ben absoluut niet tegen het forken van projecten, dat brengt diversiteit.
Of je in het geval van python 2 en het wel of niet hebben van een fork daarvan, kan spreken van een vendor-lockin vind ik te betwijfelen. Stopt het niet hebben van forks je om over te stappen naar andere leveranciers/projecten?

In dit geval denk ik niet dat het hebben van een 'legacy-fork' de diversiteit positief gaat beïnvloeden. Als ik naar snel naar de github pagina kijk dan lijken ze Python 3 features te willen bock-porten. In mijn ogen is dit niet de meest toekomstbestendige keuze voor een project.

[rkeet]

Van de andere kant valt ontwikkelaars van Python te verwijten dat ze minimaal 3 backwards compability breaks die grote impact hebben in versie 3 hebben gegooid.

Er valt developers helemaal niks verwijten wat betreft geen backwards compatibility bij major version releases. Enige backwards compatibility wel gegeven bij major versions moet je als developer dankbaar voor zijn.

Je mag, als developer, backwards compatibility verwachten voor _minor_ updates (uitgaande van semantic versioning) en uiteraard bugfix-releases.

Betekenend:
- Geen BC van 1.x.x naar 2.x.x
- Wel BC van 1.1.x naar 1.2.x en 1.1.1 naar 1.1.2

[RoestVrijStaal]

Je hebt major releases en major releases.

Idealiter wil je een major release waarvan één specifiek ding backwards incompatible is, zodat de migratie makkelijker (gepland) kan worden.

Hoe meer je backwards incompatible changes opstapelt naar één major release, hoe lastiger en meer werk de migratie wordt.

Het is geen crime om voor elke breaking incompatible change een major release uit te brengen.

[ocf81]

Ja, maar wel rijkelijk laat. Python 3 is niet volledig compatibel met Python 2. Als je nu nog een applicatie moet gaan omgooien naar Python 3 ben je er wellicht niet meer op tijd bij.

[Noxious]

Nouja, rijkelijk laat.. Het is al wel even bekend: https://github.com/python/devguide/pull/344, en dat is al na uitstel: https://www.python.org/dev/peps/pep-0373/#id2

Daarnaast is het natuurlijk absoluut de eigen verantwoordelijkheid van bedrijven om hier alert op te zijn.
Ik zie een dergelijk bericht van het NCSC meer als een 'last effort' om toch nog dingen gedaan te krijgen.

Bedrijven die nog op Python 2 leunen zijn er rijkelijk laat mee.

[qlum]

Zover ik weet heeft het nog lang geduurd voordat alle grote libaries voor pyhon2 ook op python3 werkte. voor applicaties die op die libaries rusten kan het best zo zijn dat ze helemaal niet zo veel tijd hebben gehad om te migreren.

[TheVivaldi]

Dan hadden ze de migratie van die bibliotheken zélf op zich kunnen nemen.

[Sir Isaac]

Probleem was dat je programma's / scripts niet alleen van python gebruik maken maar ook van libraries. Een aantal libraries was heel laat met porting (wxPython, matplotlib) naar python 3, waardoor ik pas recent overgestapt ben naar python3 voor mijn scripts.

[deadinspace]

Een aantal libraries was heel laat met porting (wxPython, matplotlib) naar python 3, waardoor ik pas recent overgestapt ben naar python3 voor mijn scripts.

Je opmerking over Matplotlib verbaasde me een beetje, omdat ik dat vaker gebruikt heb en al jaren geen Python 2 meer programmeer... Ik heb even naar de versiegeschiedenis gekeken, en ik denk dat je je vergist over Matplotlib:

• Matplotlib ondersteunt Python 3 sinds versie 1.2.0 van november 2012.
• Matplotlib ondersteunt zelfs geen Python 2 meer sinds versie 3.0.0 van september 2018

Matplotlib met Python 3 kan dus al 7 jaar, en als je de laatste versie wil gebruiken is het zelfs onmogelijk met Python 2 sinds bijna een jaar

[Reactie gewijzigd door deadinspace op 23 juli 2024 04:19]

[Tokkes]

Ergens mee akkoord. Ik roep ook al anderhalf jaar dat we dit soort werk gaan moeten scopen en nu zitten we ondertussen al in Augustus 2019 en er is nog niets gebeurd...

[deadinspace]

Uit statistieken van de Python Package Index blijkt dat in ieder geval in juni 2019 het gros van de downloads nog packages voor Python 2.x-versies waren.

Dat vind ik wel een beetje misleidend geformuleerd... Als je naar de download statistieken van alle PyPI packages kijk (derde grafiek) dan zie je inderdaad dat in juni er meer downloads waren van Python 2 packages dan Python 3, maar dat het verschil misschien 10% is (45% vs 55%). Dat is subtieler dan het woordgebruik "het gros" voor mij impliceert. Bovendien is in diezelfde grafiek te zien dat sinds pak hem beet half juli Python 3 aan kop ligt.

Overigens vind ik het wel schokkend dat nog steeds ongeveer de helft van de downloads Python 2 packages zijn, daar niet van. Maar wat mij betreft had dit wel wat nauwkeuriger gepresenteerd mogen worden in het artikel.

[gekkie]

Vrees dat het wellicht mede komt omdat de default interpreter en dus ook pip voor een hoop (LTS) linux distributies nog python2 is ipv 3 ?

[deadinspace]

Als je met "default interpreter" bedoelt dat /usr/bin/python Python 2 start: dat is puur voor compatibility redenen. Vrijwel alle Python 2 programma's gebruiken #! /usr/bin/python (of de env-variant) als shebang en werken dus niet meer als die executable Python 3 is.

De huidige recommendation staat wel toe dat /usr/bin/python naar Python 3 verwijst, maar dat is pas sinds juli dit jaar het geval.

Python programma's zouden altijd expliciet #! /usr/bin/env python2 of #! /usr/bin/env python3 moeten gebruiken, maar dat is voor de eerste van die twee helaas niet het geval.

@gekkie Het was ook geen kritiek, meer een verduidelijking

@assembler dat is ook niet gegarandeerd de beste oplossing, maar je hebt gelijk dat het voor Python vaak beter is. Ik heb de voorbeelden dan ook aangepast!

[Reactie gewijzigd door deadinspace op 23 juli 2024 04:19]

[gekkie]

Klopt, misschien beetje onhandig verwoord van me.
Maar als je niet helemaal "into python" bent, maar er wel wat mee wilt, als was het maar wat admin scriptjes draaien dan lijkt me de kans groter dat je op python en pip uitkomt dan bij python3 en pip3.

Tevens onthoudt het internet veel en dus ook een hoop oude tutorials, met python en pip.

Dus ik kan het me voorstellen dat dat een deel van de nog aanzienlijke python2 package downloads zou kunnen verklaren.

Andere is misschien dat een deel auto downloads zijn van CI-straten die ook op python2 compatability testen, kan ook nog best vertekend beeld geven.

[assembler]

#! /usr/bin/env python3 dus graag... zodat script ook in een virtual environment werken.

[xfj]

https://pythonclock.org

[todhoward]

Kan pip3 dan lekker hernoemt worden naar pip en pip2 terug naar pip2?
Ik ben zeker dat ik deels verantwoordelijk ben voor de hogere cijfers voor Python 2 package downloads!/s
Als je een virtual environment opzet met "virtualenv -p python3 envname" dan verwijst pip namelijk naar pip3 / python 3 pip maar zowat elke distro is default pip die voor python 2 (pip2), heb al een paar keer meegemaakt dat ik naar de verkeerde terminal ging die niet de virtualenv geactiveerd had om een package te installeren en automatisch "pip install" in typte.
Misschien wat PEBCAK (en je kan altijd pip3 symlinken naar pip handmatig) maar zou toch fijn zijn omdat fingerspitzengefühl tegen te gaan.

[jopiek]

Aardig om te zien dat met name voor Machine Learning de downloads voor 3 het winnen van 2.

@todhoward, dat zou idd erg prettig zijn, ik gebruik altijd Python 3 maar je moet er idd altijd eventjes over nadenken, ook met starten moet je python3 doen natuurlijk, zou ook gewoon de default voor python moeten worden.