image

Britse overheid waarschuwt voor einde ondersteuning Python 2

vrijdag 23 augustus 2019, 08:04 door Redactie, 22 reacties

De Britse overheid heeft organisaties en ontwikkelaars gewaarschuwd voor het einde van de ondersteuning van Python 2. De programmeertaal zal vanaf 1 januari 2020 geen beveiligingsupdates meer ontvangen. "Als je nog steeds Python 2.x gebruikt is het tijd om je code naar Python 3 om te zetten", aldus het Britse National Cyber Security Centre (NCSC) in een blogposting.

Ontwikkelaars die van niet meer ondersteunde modules gebruik blijven maken riskeren de veiligheid van hun organisaties en gegevens, aangezien er vroeger of later kwetsbaarheden zullen verschijnen waar geen updates meer voor uitkomen, zo laat de waarschuwing weten. In het geval het migreren naar Python 3 geen optie is wordt aangeraden om een commercieel bedrijf in te schakelen om Python 2 te blijven ondersteunen.

Het NCSC heeft daarnaast een overzicht van de tien populairste Python-packages gemaakt. Packages die miljoenen keren per maand worden gedownload. Het grootste deel van deze downloads betreft nog steeds de Python 2-versie, ook al is er een Python 3-versie beschikbaar. "Zelfs als slechts een fractie van deze downloads in live projecten wordt gebruikt kan de end-of-life van Python 2 de veiligheid van miljoenen systemen in gevaar brengen", aldus de Britse overheidsinstantie.

Reacties (22)
23-08-2019, 08:28 door Anoniem
Dat met dat "we stoppen met de ondersteuning" is dus niet zo'n practisch ideetje. En maakt het project [x] ongeschikt om in de lange termijn op te vertrouwen. Want je kan er niet vanuitgaan dat een bestaand script het over tien jaar nog steeds zal doen met de dan gangbare versie van de scriptingtaal en je moet wel de scriptingtaal bijwerken want anders beveiligingsgaten. Er zit dus een verwachting in van je scripts regelmatig bijwerken zodat ze het met de dan-gangbare versie van de scriptingtaal blijven doen. Dit is zeker niet de enige scriptingtaal met dit specifieke probleem, overigens. Maar wel iets om over na te denken als je scriptingtaaltjes inzet binnen je organisatie.
23-08-2019, 10:16 door Anoniem
Door Anoniem: Maar wel iets om over na te denken als je scriptingtaaltjes inzet binnen je organisatie.

Je framet het nu alsof dit een typisch probleem is van 'scriptingtaaltjes', maar dit geldt natuurlijk voor elke IT oplossing. Hele overheidsorganisaties konden bijvoorbeeld geen windows upgraden omdat ze een applicatie hadden die een bepaalde browserversie vereisten...
23-08-2019, 10:27 door Anoniem
Door Anoniem: Dat met dat "we stoppen met de ondersteuning" is dus niet zo'n practisch ideetje. […]
Wellicht is wat achtergrond handig: De end-of-life (EOL) van Python2 is op november 2008 aangekondigd voor 2015 en uitgesteld op juni 2016 tot 2020 [bron: https://legacy.python.org/dev/peps/pep-0373/]. Al met al is het dus al meer dan 10 jaar duidelijk dat Python2 EOL raakt. Python3 werd zelf in december 2008 released.
Het hangt van ieders eigen situatie af of 10 jaar lang of kort is.
23-08-2019, 10:55 door Anoniem
ik begrijp dat ik als ik van mijn Amazon linux distributie python27 verwijder de hele distro niet meer werkt. Wel kan ik versie 3.6.x toevoegen en zorgen dat deze in terminal sessie wordt gebruikt. Wel even oppassen dus als je hiermee aan de gang gaat...
23-08-2019, 11:26 door Anoniem
Python 2 is nog steeds de default op Ubuntu...
Zal ook niet helpen..
23-08-2019, 11:41 door Anoniem
Door Anoniem: Dat met dat "we stoppen met de ondersteuning" is dus niet zo'n practisch ideetje. En maakt het project [x] ongeschikt om in de lange termijn op te vertrouwen.
Het blijft gewoon werken, ook als het niet wordt ondersteund, dus dit is onzn.

Los daarvan is het best een goed idee om na meer dan tien jaar eindelijk eens over te stappen op de nieuwste versie.
23-08-2019, 11:42 door Anoniem
Door Anoniem: Dat met dat "we stoppen met de ondersteuning" is dus niet zo'n practisch ideetje. En maakt het project [x] ongeschikt om in de lange termijn op te vertrouwen. Want je kan er niet vanuitgaan dat een bestaand script het over tien jaar nog steeds zal doen met de dan gangbare versie van de scriptingtaal en je moet wel de scriptingtaal bijwerken want anders beveiligingsgaten.
Grappig dat je 10 jaar als termijn noemt, want Python 3.0 is in 2008 uitgekomen, meer dan 10 jaar geleden. Toen was al duidelijk dat men Python 2.x niet tot in de oneindigheid zou blijven onderhouden, maar men is dat dus wel meer dan 10 jaar blijven doen.

Het probleem met de overgang van Python2 naar Python3 is dat men een aantal van de basisdatatypes heeft veranderd. Er is geen onderscheid meer tussen ascii- en unicode-strings meer bijvoorbeeld, strings zijn unicodes en als je met ascii werkt heb je bytes nodig. Het is een welkome verbetering, voor alle duidelijkheid, het kon in Python2 in sommige omstandigheden best verwarrend zijn hoe de verschillende stringcoderingen op elkaar inwerkten (met name de interactie van Python met de o omgeving waarin het draaide kon rare dingen opleveren), maar de consequentie is wel dat Python2 en Python3 binnen dezelfde runtime fundamenteel incompatibel met elkaar zijn.

Het met Python3 meegeleverde 2to3-conversieprogramma werkt in mijn ervaring nagenoeg feilloos. Maar een grote code base overzetten waarin alles aan alles hangt is daarmee nog geen kleinigheid. Als je projecten redelijk geïsoleerd zijn van elkaar omdat ze niet allemaal in dezelfde runtime draaien dan is de conversie behoorlijk soepel te doen.

Wie wel zo'n verweven code base heeft en nu opeens een probleem krijgt heeft 10 jaar lang de tijd gehad om over die conversie na te denken en hem in te plannen. Wie dat niet gedaan heeft heeft oogkleppen op gehad.
23-08-2019, 12:15 door Anoniem
Door Anoniem: Dat met dat "we stoppen met de ondersteuning" is dus niet zo'n practisch ideetje. En maakt het project [x] ongeschikt om in de lange termijn op te vertrouwen. Want je kan er niet vanuitgaan dat een bestaand script het over tien jaar nog steeds zal doen met de dan gangbare versie van de scriptingtaal en je moet wel de scriptingtaal bijwerken want anders beveiligingsgaten. Er zit dus een verwachting in van je scripts regelmatig bijwerken zodat ze het met de dan-gangbare versie van de scriptingtaal blijven doen. Dit is zeker niet de enige scriptingtaal met dit specifieke probleem, overigens. Maar wel iets om over na te denken als je scriptingtaaltjes inzet binnen je organisatie.

Als een ondersteuning na 10 jaar stopt, en jij hebt als bedrijf het dan nog gebruikt, dan ben je als bedrijf "een beetje dom". Dit is basic "application lifecycle management" uit een boekje....
23-08-2019, 12:28 door Anoniem
Door Anoniem:
Door Anoniem: Maar wel iets om over na te denken als je scriptingtaaltjes inzet binnen je organisatie.
Je framet het nu alsof dit een typisch probleem is van 'scriptingtaaltjes', maar dit geldt natuurlijk voor elke IT oplossing.
Nee, dat doet het niet.

Als jij een programma schrijft en dat door een compiler haalt, ben je daarna van de compiler af. Tenzij de compiler op d'ene of d'andere manier onveilige code weet te genereren, maar dat is erg zeldzaam. Als er runtimes bijmoeten heb je wel weer het probleem dat die mischien bijgewerkt moeten worden. Maar gecompileerde en gestandaardiseerde talen hebben meestal wel het voordeel dat een nieuwe compiler nog wel code die de oude standaard volgt werkingsgelijk gecompileerd aflevert. En dan aan een nieuwe runtime vastklinkt, voor compilers die dat doen.

Hele overheidsorganisaties konden bijvoorbeeld geen windows upgraden omdat ze een applicatie hadden die een bepaalde browserversie vereisten...
Je hebt gelijk dat dat een vergelijkbaar probleem is. Dan heb je jezelf dus vooraf al opgehangen aan een afhankelijkheid en had je dat dus aan kunnen zien komen. Maar je hebt geen gelijk dat dat generaliseert naar alles in de IT, zoals betoogd.


Door Anoniem:
Door Anoniem: Dat met dat "we stoppen met de ondersteuning" is dus niet zo'n practisch ideetje. En maakt het project [x] ongeschikt om in de lange termijn op te vertrouwen.
Het blijft gewoon werken, ook als het niet wordt ondersteund, dus dit is onzn.

Los daarvan is het best een goed idee om na meer dan tien jaar eindelijk eens over te stappen op de nieuwste versie.
Voor jouw thuiscomputertje mag jij het onzin vinden en kun je mischien zelfs de moeite van het overstappen bagatelliseren. Niet iedereen denkt er zo over.


Door Anoniem: Grappig dat je 10 jaar als termijn noemt,
Dat is eigenlijk veel te laag geschat. We hebben nog veel oudere code die nog in productie is.

want Python 3.0 is in 2008 uitgekomen, meer dan 10 jaar geleden. Toen was al duidelijk dat men Python 2.x niet tot in de oneindigheid zou blijven onderhouden, maar men is dat dus wel meer dan 10 jaar blijven doen.
Omdat zeker in het begin "3" een onstabiel zooitje was. Waarmee python zichzelf dus voor de lange baan disqualificeert op een andere manier.

[...] Het is een welkome verbetering, voor alle duidelijkheid, [...]
Het is maar hoe je het bekijkt. Tot op het punt dat "3" wel "python's zelfmoordbriefje" genoemd is, en niet zonder reden.

Het met Python3 meegeleverde 2to3-conversieprogramma werkt in mijn ervaring nagenoeg feilloos. Maar een grote code base overzetten waarin alles aan alles hangt is daarmee nog geen kleinigheid. Als je projecten redelijk geïsoleerd zijn van elkaar omdat ze niet allemaal in dezelfde runtime draaien dan is de conversie behoorlijk soepel te doen.
Maar je moet het dus wel doen, met alle onzekerheid van dien.

Dit soort beslissingen moeten vaak genomen worden en de uitvoering moet overzien worden door middle managers die geen flauw benul waar ze mee bezig zijn, laat staan dat ze de risicos behoorlijk kunnen inschatten. Mischien dat ze zelfs geen idee hebben van de noodzaak. Dat kleurt de zaak.

Wie wel zo'n verweven code base heeft en nu opeens een probleem krijgt heeft 10 jaar lang de tijd gehad om over die conversie na te denken en hem in te plannen. Wie dat niet gedaan heeft heeft oogkleppen op gehad.
Dat is wat te kort door de bocht.

Het is binnen de programmeerderij heel gemakkelijk om gewoon lekker je ding te doen en te verwachten dat de gebruikers wel mee zullen hobbelen (zie de hele "web"-shit show waar je bijkans iedere dag je browser moet bijwerken en nog weet je niet zeker of morgen je favoriete websites het nog wel zullen doen), met als gevolg dat als er iets misgaat blind de gebruikers de schuld geven. "Dan had je maar...", "oogkleppen op", etc.

Op z'n laatst zodra je dingen in productie neemt moet je wel nadenken, wat zijn je afhankelijkheden, hoe lang gaan die stabiel, bruikbaar, veilig blijven? Tenminste, als je later paniekvoetbal zoveel mogelijk wil vermijden. Maar als eindgebruiker zit je wel in een vervelend hoekje. Geen idee wat de programmeurs en andere knutselaars volgende week weer bedenken, hoe hard dat vanalles kapot maken, en zo verder, maar er wel geacht worden op te anticiperen. Er zijn gewoon projecten waar tien jaar verrekte kort is voor een complete migratie, en dat doe je pas nadat je doelplatform behoorlijk uitgekristalliseerd is, iets wat in 2008 zeker niet het geval was voor python 3.

Dus in zo'n geval grijpt iig het bedrijfsleven liever terug op iets wat wel die stabiliteit levert (zegt te leveren, of ze het ook werkelijk doen is een tweede), en daarmee schiet python zich hier lelijk in de voet. Waar ze zeker niet de enige mee zijn, verder, daar niet van.
23-08-2019, 15:08 door Krakatau
Door Anoniem:
Door Anoniem: Maar wel iets om over na te denken als je scriptingtaaltjes inzet binnen je organisatie.

Je framet het nu alsof dit een typisch probleem is van 'scriptingtaaltjes', maar dit geldt natuurlijk voor elke IT oplossing.

Daar zit natuurlijk wel wat in... Bijvoorbeeld Java is nogal wat professioneler qua backwards compatibility. Ik zou het dus geen 'framing' willen noemen.

Door Anoniem: Hele overheidsorganisaties konden bijvoorbeeld geen windows upgraden omdat ze een applicatie hadden die een bepaalde browserversie vereisten...

Tja, als je als organisatie Windows gebruikt dan kan ik je nog maar met moeite serieus nemen. Wat verwacht je nou daarmee?
23-08-2019, 16:40 door Briolet
Door Anoniem:
Door Anoniem:Los daarvan is het best een goed idee om na meer dan tien jaar eindelijk eens over te stappen op de nieuwste versie.
Voor jouw thuiscomputertje mag jij het onzin vinden en kun je mischien zelfs de moeite van het overstappen bagatelliseren. Niet iedereen denkt er zo over.

Het beste voorbeeld zijn wel de spaceshuttles. Daar hangen levens af van bugvrije software. Die oude software was uit den treure getest en dan neem je geen risico met een update.

Bij de Ariane 5 hebben ze wel het risico genomen. Daardoor is de eerste lancering gecrashed. Maar dat was een update van de hardware waarbij gemist werd dat er in de software nog ergens een gewicht van de Ariane 4 in de berekening stond.

Upgraden levert gewoon risico op nieuwe bugs.
23-08-2019, 18:36 door Anoniem
Tjeetje wat een negativiteit hier weer van veel mensen. Het is een beetje alsof men loopt te klagen dat ten tijde van Windows 9 "opeens" Windows 95 eol raakte, en men doet net of men zelf *alle* programmatuur die in python 2 is geschreven moet converteren.
23-08-2019, 21:56 door Anoniem
Door Anoniem:
Het is maar hoe je het bekijkt. Tot op het punt dat "3" wel "python's zelfmoordbriefje" genoemd is, en niet zonder reden.

Je kunt het oneens zijn met de ontwikkeling van Python 3, en de EOL-planning van Python 2, maar aangezien Python nog steeds ongekend sterk in populariteit groeit slaat dat "Python's zelfmoordbriefje" natuurlijk nergens op:

Popularity Index: Python Is 2018 'Language of the Year'

Python continued its rise in the TIOBE index of programming language popularity, clocking in at No. 3 in the January 2019 report and being named programming language of the year for 2018. Python also ended the year as No. 1 in the PYPL index.

(bron: https://adtmag.com/articles/2019/01/08/tiobe-jan-2019.aspx)
24-08-2019, 09:17 door Anoniem
Door Anoniem:
Door Anoniem: Grappig dat je 10 jaar als termijn noemt,
Dat is eigenlijk veel te laag geschat. We hebben nog veel oudere code die nog in productie is.
De leeftijd van code is iets anders dan de tijd die je nodig hebt voor een conversie.

Omdat zeker in het begin "3" een onstabiel zooitje was. Waarmee python zichzelf dus voor de lange baan disqualificeert op een andere manier.
Het is al lang geen instabiel zooitje meer. Het punt was dat je in 2008 al kon aan zien komen dat je er een keer aan moet geloven.

Het met Python3 meegeleverde 2to3-conversieprogramma werkt in mijn ervaring nagenoeg feilloos. Maar een grote code base overzetten waarin alles aan alles hangt is daarmee nog geen kleinigheid. Als je projecten redelijk geïsoleerd zijn van elkaar omdat ze niet allemaal in dezelfde runtime draaien dan is de conversie behoorlijk soepel te doen.
Maar je moet het dus wel doen, met alle onzekerheid van dien.
Je hebt te maken met een externe verandering die nou eenmaal gebeurt. Het is helemaal geen optie om er niets aan te doen. En nogmaals, het was al in 2008 duidelijk dat dat er een keer aan ging komen.

Dit soort beslissingen moeten vaak genomen worden en de uitvoering moet overzien worden door middle managers die geen flauw benul waar ze mee bezig zijn, laat staan dat ze de risicos behoorlijk kunnen inschatten. Mischien dat ze zelfs geen idee hebben van de noodzaak. Dat kleurt de zaak.
Zit je nou het probleem van slecht management op het bordje van een programmeertaal te leggen?

Wie wel zo'n verweven code base heeft en nu opeens een probleem krijgt heeft 10 jaar lang de tijd gehad om over die conversie na te denken en hem in te plannen. Wie dat niet gedaan heeft heeft oogkleppen op gehad.
Dat is wat te kort door de bocht.

Het is binnen de programmeerderij heel gemakkelijk om gewoon lekker je ding te doen en te verwachten dat de gebruikers wel mee zullen hobbelen (zie de hele "web"-shit show waar je bijkans iedere dag je browser moet bijwerken en nog weet je niet zeker of morgen je favoriete websites het nog wel zullen doen), met als gevolg dat als er iets misgaat blind de gebruikers de schuld geven. "Dan had je maar...", "oogkleppen op", etc.
Wat je ook van de wijziging vindt, voor negeren dat hij eraan komt vind ik het terecht om van oogkleppen te spreken. Net zo goed als een bedrijf met een wagenpark om goederen te bezorgen rekening moet houden met het toenemende aantal steden dat vuile diesels weert, of een afvalverwerker die het onderhoud en de modernisering van zijn overns niet moet laten versloppen. Als je je afhankelijk maakt van technologie dan heb je aandacht te besteden aan hoe die technologie ervoor staat en hoe de ontwikkelingen rond die technologie je kunnen beïnvloeden. Dat is met software niet anders.

Op z'n laatst zodra je dingen in productie neemt moet je wel nadenken, wat zijn je afhankelijkheden, hoe lang gaan die stabiel, bruikbaar, veilig blijven? Tenminste, als je later paniekvoetbal zoveel mogelijk wil vermijden.
Dat is precies het punt dat ik maak.
Maar als eindgebruiker zit je wel in een vervelend hoekje. Geen idee wat de programmeurs en andere knutselaars volgende week weer bedenken, hoe hard dat vanalles kapot maken, en zo verder, maar er wel geacht worden op te anticiperen. Er zijn gewoon projecten waar tien jaar verrekte kort is voor een complete migratie, en dat doe je pas nadat je doelplatform behoorlijk uitgekristalliseerd is, iets wat in 2008 zeker niet het geval was voor python 3.
Nogmaals, dat Python3 in 2008 nog niet goed genoeg was is het punt niet, het punt is dat toen duidelijk was dat die bittere pil eraan zit te komen. Voor zover mij bekend is het argument dat allerlei libraries en frameworks niet over zijn gegaan inmiddels achterhaald. En behalve 2to3 zijn er andere conversiemogelijkheden, bijvoorbeeld de six-library waarmee je code kan maken die onder beide Python-versies draait en waarvoor ook alweer een conversie-utility beschikbaar is. Dit is een korte beschrijving van een tent die een 15 jaar oude code base van 240.000 regels (commentaar en lege regels niet meegeteld) langs die weg in anderhalf jaar heeft geconverteerd:
https://medium.com/@boxed/moving-a-large-and-old-codebase-to-python3-33a5a13f8c99
24-08-2019, 10:37 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem: Grappig dat je 10 jaar als termijn noemt,
Dat is eigenlijk veel te laag geschat. We hebben nog veel oudere code die nog in productie is.
De leeftijd van code is iets anders dan de tijd die je nodig hebt voor een conversie.
Waarom zou je iedere tien jaar een upgradeslag met al je code moeten doen als je ook vijftig+ jaar lang gewoon dezelfde code kan gebruiken?

Omdat zeker in het begin "3" een onstabiel zooitje was. Waarmee python zichzelf dus voor de lange baan disqualificeert op een andere manier.
Het is al lang geen instabiel zooitje meer. Het punt was dat je in 2008 al kon aan zien komen dat je er een keer aan moet geloven.
Die teller gaat mischien voor de python-programmeurs lopen in 2008. Voor hen die er op bouwen willen, niet. Als je het over "niet hetzelfde" hebt, deze twee moet je niet conflateren.

Het met Python3 meegeleverde 2to3-conversieprogramma werkt in mijn ervaring nagenoeg feilloos. Maar een grote code base overzetten waarin alles aan alles hangt is daarmee nog geen kleinigheid. Als je projecten redelijk geïsoleerd zijn van elkaar omdat ze niet allemaal in dezelfde runtime draaien dan is de conversie behoorlijk soepel te doen.
Maar je moet het dus wel doen, met alle onzekerheid van dien.
Je hebt te maken met een externe verandering die nou eenmaal gebeurt. Het is helemaal geen optie om er niets aan te doen. En nogmaals, het was al in 2008 duidelijk dat dat er een keer aan ging komen.
Nou, dat is verandering die arbitrair door de python-jongens erdoor gedrukt wordt voor hun eigen gemak. Wil je als eindgebruiker het risico lopen gedwongen worden je bedrijfscritische processen aan te moeten passen aan de nukken van zulke cowboys? Daar is niets "nou eenmaal" aan, dat is een valide vraag en wellicht een goed idee om dan maar niet voor python te kiezen. Er zijn talen waar dat echt anders werkt.

Dit soort beslissingen moeten vaak genomen worden en de uitvoering moet overzien worden door middle managers die geen flauw benul waar ze mee bezig zijn, laat staan dat ze de risicos behoorlijk kunnen inschatten. Mischien dat ze zelfs geen idee hebben van de noodzaak. Dat kleurt de zaak.
Zit je nou het probleem van slecht management op het bordje van een programmeertaal te leggen?
Het is geen schuld-en-boete verhaal. Meer een verhaal van welke realiteit de eindgebruikers in leven en dat die anders is dan de realiteit van de programmeur-knutselaars. Als dat te ver uitelkaar ligt dan is het als eindgebruiker onverstandig je met het noeste knutselwerk van de programmeur-knutselaars in te laten.

We hebben het over bouwen op elkaar. Welke gebouweigenaar vindt het prettig om iedere tien jaar zijn gebouw van nieuwe palen te moeten voorzien omdat de oude de verkeerde maat blijken te hebben? "Nieuwe inzichten? mijn laars!", denkt zo'n gebouweigenaar.

Wie wel zo'n verweven code base heeft en nu opeens een probleem krijgt heeft 10 jaar lang de tijd gehad om over die conversie na te denken en hem in te plannen. Wie dat niet gedaan heeft heeft oogkleppen op gehad.
Dat is wat te kort door de bocht.

Het is binnen de programmeerderij heel gemakkelijk om gewoon lekker je ding te doen en te verwachten dat de gebruikers wel mee zullen hobbelen (zie de hele "web"-shit show waar je bijkans iedere dag je browser moet bijwerken en nog weet je niet zeker of morgen je favoriete websites het nog wel zullen doen), met als gevolg dat als er iets misgaat blind de gebruikers de schuld geven. "Dan had je maar...", "oogkleppen op", etc.
Wat je ook van de wijziging vindt, voor negeren dat hij eraan komt vind ik het terecht om van oogkleppen te spreken.
Ik vind het te kort door de bocht. Als je het over schuld en boete hebt, de schuld ligt bij de programmeur-knutselaars, en die leggen de rekening zonder blikken of blozen bij de eindgebruiker. En jij ook.

Net zo goed als een bedrijf met een wagenpark om goederen te bezorgen rekening moet houden met het toenemende aantal steden dat vuile diesels weert,
Waarbij de definitie van "vuile diesels" volstrekt arbitrair blijkt te zijn, en niet gebaseerd op wat er werkelijk uit de uitlaat komt. Dat laatste detail vind ik kwalijk en laakbaar. Kijk niet naar de brandstof en kijk niet naar het jaar waarin het ding volgens de papieren gebouwd is. Kijk naar wat er werkelijk uit de uitlaat komt.

Dat sommige van die dingen liegen op de testbank is een ander verhaal. Het enige wat zou mogen tellen is wat er in normaal gebruik uit de uitlaat komt. Al het andere is volksverlakkerij.

En ja, dan moet je dus ook benzineautos en zelfs hybrideautos meenemen. En bussen, vrachtautos, invalidekarretjes, motorfietsen, brommers, scooters, noem-maar-op. Bootjes en gensets ook. Alles met een uitlaat. Mischien moet je zelfs met uitstoot-per-persoon en uitstoot-per-kg-vracht gaan werken, weet jij veel. Dat wordt lastig, ja. Dus grijpt "men" maar naar wat arbitraire en bijkans ongerelateerde andere meetlatten, waarmee ze zichzelf vooral als volstrekt incompetente bestuurders afschilderen. Maar hee, het lijkt net of ze wat nuttigs bereikt hebben, als ze maar genoeg door hun wimpers kijken en vol daglicht mijden.

of een afvalverwerker die het onderhoud en de modernisering van zijn overns niet moet laten versloppen. Als je je afhankelijk maakt van technologie dan heb je aandacht te besteden aan hoe die technologie ervoor staat en hoe de ontwikkelingen rond die technologie je kunnen beïnvloeden. Dat is met software niet anders.
Nou, dan is enkel de technologie gebruiken en af en toe paniekvoetbal omdat de makers het nodig vinden de scriptingtaal waar je op bouwt compleet om te gooien, niet voldoende. Niet voor de eindgebruiker, maar ook niet voor de programmeur-knutselaars. Beide hebben een professionaliseringsslag nodig.

Dat het wel de mode is, tsja. We gaan nu "met z'n allen" vol op het orgel voor de warmptepompen, die nu al duurder, luider, minder goed, en oh ja, ook al niet echt beter voor het milieu, blijken dan de gasverbruikende installaties die ze maar even moeten vervangen. Waarbij de rekening dus ook op het bordje van de eindgebruiker wordt gelegd, omwille van politieke idealen reeds achterhaald voor ze goed en wel nagestreefd worden. Dat is wat je noemt politieke luchtfietserij, en laakbaar.

Op z'n laatst zodra je dingen in productie neemt moet je wel nadenken, wat zijn je afhankelijkheden, hoe lang gaan die stabiel, bruikbaar, veilig blijven? Tenminste, als je later paniekvoetbal zoveel mogelijk wil vermijden.
Dat is precies het punt dat ik maak.
Met een hoop schuld op de eindgebruiker z'n bordje zonder naar de programmeur-knutselaar te willen kijken.

Maar als eindgebruiker zit je wel in een vervelend hoekje. Geen idee wat de programmeurs en andere knutselaars volgende week weer bedenken, hoe hard dat vanalles kapot maken, en zo verder, maar er wel geacht worden op te anticiperen. Er zijn gewoon projecten waar tien jaar verrekte kort is voor een complete migratie, en dat doe je pas nadat je doelplatform behoorlijk uitgekristalliseerd is, iets wat in 2008 zeker niet het geval was voor python 3.
Nogmaals, dat Python3 in 2008 nog niet goed genoeg was is het punt niet, het punt is dat toen duidelijk was dat die bittere pil eraan zit te komen.
Maar die teller voor wat een redelijke overgansgperiode is hoort niet bij de eerste alpha te gaan lopen. Dus ik accepteer "het is nu elf jaar na 2008, dus ruim voldoende tijd gehad" niet als goed argument.

Voor zover mij bekend is het argument dat allerlei libraries en frameworks niet over zijn gegaan inmiddels achterhaald.
Ik heb er niet op gelet, maar zulke achterhaaldheids-schattingen komen van rooskleurigkijkende proponenten en gaan over de populairste publiekelijk-beschikbare dingen. "De ene die je net nodig hebt" hoeft dat niet te zijn, maar kan bijvoorbeeld bedrijfsintern zijn, of iets anders, maar is de ene die net telt voor jouw specifieke project.

En behalve 2to3 zijn er andere conversiemogelijkheden, bijvoorbeeld de six-library waarmee je code kan maken die onder beide Python-versies draait en waarvoor ook alweer een conversie-utility beschikbaar is. Dit is een korte beschrijving van een tent die een 15 jaar oude code base van 240.000 regels (commentaar en lege regels niet meegeteld) langs die weg in anderhalf jaar heeft geconverteerd:
https://medium.com/@boxed/moving-a-large-and-old-codebase-to-python3-33a5a13f8c99
Het meervoud van "anecdote" is niet "data". Maargoed, een enkele codebase, waar dus tijdig iemand op gesprongen is en het kostte nog steeds anderhalf jaar. Dat kun je zien als best case. Maar dan is er nog altijd een enorme "long tail" van minder goede cases. Die allemaal als "met oogkleppen op" wegzetten is niet heel productief.

We weten dat de praktijk weerbarstig is. Heeft er iemand al eens uitgevogeld waarom, ik noem een dwarsstraat, windows XP zoveel langer dan door de fabrikant gewenst een ding geweest is, en waarom het nog steeds her-en-der in productie opduikt?
25-08-2019, 10:31 door Anoniem
Ik heb me helemaal op Python 2 toegespitst. Dit gaat heel vervelend worden voor mijn switch en alles wat ik opnieuw moet schrijven als het door mijn werkgever niet meer wordt ondersteund, wat sneller kan komen dan verwacht.

Goed voor mijn baangarantie dat nog wel.
25-08-2019, 12:32 door Anoniem
Door Anoniem: Waarom zou je iedere tien jaar een upgradeslag met al je code moeten doen als je ook vijftig+ jaar lang gewoon dezelfde code kan gebruiken?
Niet iedere 10 jaar, het is één keer gebeurd met een transitieperiode van ruim 10 jaar. Dat is iets volkomen anders.

Nou, dat is verandering die arbitrair door de python-jongens erdoor gedrukt wordt voor hun eigen gemak.
Niet arbitrair, niet voor het eigen gemak. Als ze voor gemak kozen hadden ze niet de moeite genomen om een programmeertaal te ontwikkelen. Dat is niet triviaal, weet je?

De afweging was om een aantal achteraf gezien ongelukkige ontwerpkeuzes uit 1.x en 2.x te laten vervallen of Python in de toekomst ermee te blijven belasten. De inschatting om voor het eerste te kiezen was dat de nadelen op kortere termijn niet op zouden wegen tegen de voordelen op de langere termijn, ook voor de gebruikers van de taal. Dat je het niet eens bent met die keuze, en zelfs dat de conversieproblemen groter zijn dan men had ingeschat, betekent nog niet dat het een keuze voor het eigen gemak was.

Als je het over schuld en boete hebt, de schuld ligt bij de programmeur-knutselaars, en die leggen de rekening zonder blikken of blozen bij de eindgebruiker.
Als je het over rekeningen hebt moet je je eens afvragen of die eindgebruiker wel een betalende klant is van de Python Software Foundation. Wat voor relatie denk je eigenlijk dat die met gebruikers van Python hebben? Python is een standaard voor een programmeertaal, en CPython is de referentie-implementatie van die standaard. Naast CPython zijn er ook andere implementaties, zoals PyPy, Jython, IronPython en diverse implementaties van subsets van Python.

Je hoeft maar een klein beetje aandacht te hebben besteed aan hoe CPython wordt ontwikkeld om te hebben opgemerkt dat het eenvoudig houden van de interpreter en runtime een hoge prioriteit heeft. Als jij wilt dat Python2 langer ondersteund wordt of Python2 en Python3 in hetzelfde interpreterproces kunnen draaien dan vraag je om een forse toename van de complexiteit, wat onvermijdelijk grotere inspanning en hogere kosten oplevert voor de Python Software Foundation.

Jij klaagt dat die de rekening zonder blikken of blozen leggen bij de eindgebruiker die vermoedelijk in de meeste gevallen geen cent bijdraagt aan de ontwikkeling van Python. Heb je door dat jij zonder blikken of blozen rekeningen bij de ontwikkelaars legt zonder een cent ervoor te betalen?

En jij ook.
Kul. Ik doe niets anders dan een mening erover hebben. Ik ben totaal niet betrokken bij de ontwikkeling van Python, ik gebruik het alleen al vele jaren voor diverse softwareprojecten, die ook inmiddels al jaren geleden zonder noemenswaardige problemen naar Python3 zijn omgezet.

Waarbij de definitie van "vuile diesels" volstrekt arbitrair blijkt te zijn, en niet gebaseerd op wat er werkelijk uit de uitlaat komt. Dat laatste detail vind ik kwalijk en laakbaar. Kijk niet naar de brandstof en kijk niet naar het jaar waarin het ding volgens de papieren gebouwd is. Kijk naar wat er werkelijk uit de uitlaat komt.
Nee, zet al die oordelen opzij en kijk naar het praktische feit dat die auto's door veel steden geweerd worden. Al je tegenargumenten veranderen niets aan dat feit, en als het je vermogen om als bedrijf te functioneren beïnvloedt ben je heel dom bezig als je je hakken in de grond blijft zetten tot je in de situatie zit dat je je werk niet meer kan doen. Dat bedoel ik met oogkleppen op hebben. Je laat zien dat je er behoorlijk last van hebt.

En ja, dan moet je dus ook benzineautos en zelfs hybrideautos meenemen. En bussen, vrachtautos, invalidekarretjes, motorfietsen, brommers, scooters, noem-maar-op. Bootjes en gensets ook. Alles met een uitlaat.
Amsterdam weert oudere scooters en vervuilende vrachtauto's. Bussen in Amsterdam rijden op gas of elektrisch. Met scheepvaart is men ook bezig, men wil bijvoorbeeld de cruise terminal uit het centrum weghebben. Je neemt aan dat men inconsequent is maar als je eens naar de feiten kijkt blijkt het beeld heel anders te zijn. Hoe andere steden het doen weet ik niet, ik houd niet alles en iedereen in de gaten.

Maar die teller voor wat een redelijke overgansgperiode is hoort niet bij de eerste alpha te gaan lopen. Dus ik accepteer "het is nu elf jaar na 2008, dus ruim voldoende tijd gehad" niet als goed argument.
Die teller gaat lopen op het moment dat een einddatum voor support wordt afgegeven. Als jij ervoor kiest zo'n mededeling te negeren omdat op dat moment de nieuwe software nog niet goed genoeg is en vervolgens ervoor kiest het de tien jaar na die mededeling te blijven negeren terwijl die software inmiddels wel degelijk is dan doe je jezelf de ellende aan waar je nu over kankert. Kom eens uit die kankermodus en kijk naar wat er gedaan moet worden.

Ik heb er niet op gelet, maar zulke achterhaaldheids-schattingen komen van rooskleurigkijkende proponenten en gaan over de populairste publiekelijk-beschikbare dingen. "De ene die je net nodig hebt" hoeft dat niet te zijn, maar kan bijvoorbeeld bedrijfsintern zijn, of iets anders, maar is de ene die net telt voor jouw specifieke project.
Dat krijg je als je geen rekening houdt met de ontwikkelingen. De bedrijfsinterne component moet gewoon net als je andere eigen software geconverteerd worden - of zijn. Voor componenten van leveranciers die hardnekkig op 2.x blijven zitten heb je als je het goed doet al lang die leveranciers aangesproken en als er geen beweging in zit alternatieven onderzocht.

Het meervoud van "anecdote" is niet "data". Maargoed, een enkele codebase, waar dus tijdig iemand op gesprongen is en het kostte nog steeds anderhalf jaar. Dat kun je zien als best case. Maar dan is er nog altijd een enorme "long tail" van minder goede cases. Die allemaal als "met oogkleppen op" wegzetten is niet heel productief.
Waarmee je je kop in het zand steken tot norm verheft. Voor mij is dat gedrag niet productief. Productief is het om op tijd te reageren op aangekondigde veranderingen zodat je niet klem komt te zitten. Je kan zwaar de schurft in hebben over dát die veranderingen eraan komen, maar met je hakken in het zand zetten los je dat niet op.

Die conversie laat zien dat het kennelijk kan, en daar was tien jaar echt niet onvoldoende. De code waar ik mee te maken heb in Python is niet van die omvang, en ik heb gewoon met enige regelmaat gecheckt of externe libraries waar mijn code van afhangt al voor Python3 beschikbaar waren, en of er equivalente libraries waren waarop overgestapt kon worden. Met die benadering was ik in 2015 al volledig over.

Geen Python, maar ik heb zelf in een ver verleden een conversie van een grote code base (honderden mensjaren ontwikkelinspanning) naar een ander besturingssysteem en andere compiler meegemaakt. Zowel de andere compiler als verschillen in het besturingssysteem en aangeroepen aangekochte software leverden, net als nu met Python, de noodzaak op in alle sources aanpassingen te doen. Daar is toen een eigen conversieprogramma voor gemaakt, dat gaandeweg tijdens de conversie werd uitgebreid en bijgeschaafd op basis van wat men tegenkwam. Die hele conversie is toen met succes afgerond in ongeveer driekwart jaar, en het team dat de broncode converteerde bestond uit slechts drie mensen, een fractie van de ontwikkelafdeling van dat bedrijf.

Je kan het allemaal zo groot en zo erg mogelijk maken en daar al je energie aan verspillen, maar ik denk dat het in de meeste gevallen gewoon goed te doen moet zijn.
25-08-2019, 16:12 door Anoniem
Door Anoniem:
Door Anoniem: Waarom zou je iedere tien jaar een upgradeslag met al je code moeten doen als je ook vijftig+ jaar lang gewoon dezelfde code kan gebruiken?
Niet iedere 10 jaar, het is één keer gebeurd met een transitieperiode van ruim 10 jaar. Dat is iets volkomen anders.
Hebben ze beloofd dat ze nooit meer backwards-incompatible veranderingen doorvoeren? Ik weet dus niet hoe volkomen dat anders gaat zijn. En dat weegt wel mee in de rekening.

Nou, dat is verandering die arbitrair door de python-jongens erdoor gedrukt wordt voor hun eigen gemak.
Niet arbitrair, niet voor het eigen gemak. Als ze voor gemak kozen hadden ze niet de moeite genomen om een programmeertaal te ontwikkelen. Dat is niet triviaal, weet je?
Programmeertalen zijn gemaksvehikels bij uitstek. Ondanks de enorme berg moeite die heel veel mensen gestoken hebben en nog steeds steken in het ontwikkelen van allerlei programmeertalen.

De afweging was om een aantal achteraf gezien ongelukkige ontwerpkeuzes uit 1.x en 2.x te laten vervallen of Python in de toekomst ermee te blijven belasten. De inschatting om voor het eerste te kiezen was dat de nadelen op kortere termijn niet op zouden wegen tegen de voordelen op de langere termijn, ook voor de gebruikers van de taal. Dat je het niet eens bent met die keuze, en zelfs dat de conversieproblemen groter zijn dan men had ingeschat, betekent nog niet dat het een keuze voor het eigen gemak was.
Dat laatste dus overduidelijk wel, maar laten we het terzijde schuiven. Het punt was dus inderdaad dat ze dat vooral voor en vanuit eigen perspectief gedaan hebben. En dat past niet altijd bij het perspectief van de eindgebruiker. Ook al staat het er wat gechargeerd, je kan dat niet zomaar wegwuiven.

Dus als lange termijn belangrijk is voor je organisatie, dan is dat een punt tegen python (en nog veel meer andere taaltjes ook; php, ruby, node.js, allerlei fly-by-night andere talen en taaltjes). Als je nu concludeert dat er maar verrekte weinig taaltjes overblijven na dat filter, dat is correct.

Als je het over schuld en boete hebt, de schuld ligt bij de programmeur-knutselaars, en die leggen de rekening zonder blikken of blozen bij de eindgebruiker.
Als je het over rekeningen hebt moet je je eens afvragen of die eindgebruiker wel een betalende klant is van de Python Software Foundation.
Dat is alleen maar relevant als je het over betalende klanten wil hebben. Ook als er niet betaald wordt zit er wel een prijskaartje aan het gebruik. Het is een veelgebruikte dooddoener om te zeggen dat als je niet betaalt je dus niets mag zeggen, maar dat is niet zo. Je kan vanalles zeggen maar je hoeft niet te verwachten dat anderen onbezoldigd moeite voor jou gaan doen. Dat is wat anders. Tenminste voor jezelf mag je zeker wel de afweging maken of het complete plaatje van jouw kosten, ongeacht wie je ze betaalt, opwegen tegen de baten voor jouw gebruik.

Wat voor relatie denk je eigenlijk dat die met gebruikers van Python hebben? Python is een standaard voor een programmeertaal, en CPython is de referentie-implementatie van die standaard.
Dan zorg je toch dat je de versie twee van die referentie-implementatie betaald nog langer in de lucht houdt, eventueel gecomplimenteerd met een betaalde overzetdienst? Lijkt me een gouden combinatie voor een consultingbedrijfje.

Het is wel linke soep: Doe je het te graag, lijk je mensen jouw betaalde diensten in te drukken, loop je kans dat ze massaal en heel hard weg gaan rennen. Dus doe het met stijl. Maar de kans ligt er.

Je hoeft maar een klein beetje aandacht te hebben besteed aan hoe CPython wordt ontwikkeld om te hebben opgemerkt dat het eenvoudig houden van de interpreter en runtime een hoge prioriteit heeft. Als jij wilt dat Python2 langer ondersteund wordt of Python2 en Python3 in hetzelfde interpreterproces kunnen draaien dan vraag je om een forse toename van de complexiteit, wat onvermijdelijk grotere inspanning en hogere kosten oplevert voor de Python Software Foundation.
Mischien is dat omdat ze een stel prutsers zijn die de zaken niet eenvoudig hebben weten te houden?

Je hebt wel gelijk dat een hele hoop complexiteit meegezeuld wordt als gevolg van eerdere beslissingen, maar dat is nog geen vrijbrief voor wat je besluit wel mee te torsen, noch dat die latere beslissingen over wat wel en niet mee te nemen valideert.

Maargoed, ik hoef niet zonodig 2 en 3 in hetzelfde proces. Belangrijker was hier de opmerking dat als interpreter-taaltje je altijd afhankelijk bent van de interpreter. Een eenmaal gecompileerd C-programma heeft die afhankelijkheid niet. Dat scheelt vrij enorm in de complexiteit van het (deel van het) mechaniek dat werkelijk in productie belandt.

Jij klaagt dat die de rekening zonder blikken of blozen leggen bij de eindgebruiker die vermoedelijk in de meeste gevallen geen cent bijdraagt aan de ontwikkeling van Python. Heb je door dat jij zonder blikken of blozen rekeningen bij de ontwikkelaars legt zonder een cent ervoor te betalen?
Nee, de schuld leg ik zonder ze te betalen bij de ontwikkelaars. Of zelfs zonder python te gebruiken.

(Voor de volledigheid: Ik gebruik (een steenoude) python (2) zo nu en dan, maar niet op zo'n wijze dat ik niet meer zonder kan. Moet ik die gedwongen verhuizen dan is de kans groot dat ik een ander vehikel dan python versie 3 pak.)

En jij ook.
Kul. Ik doe niets anders dan een mening erover hebben. Ik ben totaal niet betrokken bij de ontwikkeling van Python, ik gebruik het alleen al vele jaren voor diverse softwareprojecten, die ook inmiddels al jaren geleden zonder noemenswaardige problemen naar Python3 zijn omgezet.
Die houden we even aan.

Waarbij de definitie van "vuile diesels" volstrekt arbitrair blijkt te zijn, en niet gebaseerd op wat er werkelijk uit de uitlaat komt. Dat laatste detail vind ik kwalijk en laakbaar. Kijk niet naar de brandstof en kijk niet naar het jaar waarin het ding volgens de papieren gebouwd is. Kijk naar wat er werkelijk uit de uitlaat komt.
Nee, zet al die oordelen opzij en kijk naar het praktische feit dat die auto's door veel steden geweerd worden. Al je tegenargumenten veranderen niets aan dat feit, en als het je vermogen om als bedrijf te functioneren beïnvloedt ben je heel dom bezig als je je hakken in de grond blijft zetten tot je in de situatie zit dat je je werk niet meer kan doen. Dat bedoel ik met oogkleppen op hebben. Je laat zien dat je er behoorlijk last van hebt.
Dat is veel meer een vooroordeel van jouw kant. Je verbindt namelijk mijn analyse van wat die "veel steden" doen en mijn waardeoordeel over hoe zich dat tegenover het idee van de rechtsstaat verhoudt aan acties cq. gevolgen die je er zelf bijverzint.

En ja, dan moet je dus ook benzineautos en zelfs hybrideautos meenemen. En bussen, vrachtautos, invalidekarretjes, motorfietsen, brommers, scooters, noem-maar-op. Bootjes en gensets ook. Alles met een uitlaat.
Amsterdam weert oudere scooters en vervuilende vrachtauto's. Bussen in Amsterdam rijden op gas of elektrisch. Met scheepvaart is men ook bezig, men wil bijvoorbeeld de cruise terminal uit het centrum weghebben. Je neemt aan dat men inconsequent is maar als je eens naar de feiten kijkt blijkt het beeld heel anders te zijn. Hoe andere steden het doen weet ik niet, ik houd niet alles en iedereen in de gaten.
Nou, hun invulling is dus wel inconsequent, zeker zodra je andere steden erbijpakt, en veroorzaakt een wirwar aan regels waar je als burger maar tussendoor te fietsen hebt. Maar dat je dat niet ziet omdat je moeite hebt met voorbij de A10 te kijken past ook goed in de rest van wat je schetst.

Een voorbeeld van hoe je het wel consequent doet: Had die Duitse Euro-vignetten overgenomen. Veel mensen hebben die al op de auto, welke je moet hebben staat gewoon in het kentekenbewijs, plakkertje erop en gaan. En die euro{1,2,3,4}-normering heeft een veel directere relatie met wat er uit de uitlaat komt dan het bouwjaar.

Maarja, dan kom je met feiten in deze symboolpolitiekdiscussie. Dat moeten we niet hebben met z'n allen, want hoe kunnen de steden nu nog tegen elkaar opbieden door steeds latere bouwjaren te kiezen? Want deugdrammen is zo te zien het enige punt van de hele exercitie. Feiten? Pfft, de idee!

Maar die teller voor wat een redelijke overgansgperiode is hoort niet bij de eerste alpha te gaan lopen. Dus ik accepteer "het is nu elf jaar na 2008, dus ruim voldoende tijd gehad" niet als goed argument.
Die teller gaat lopen op het moment dat een einddatum voor support wordt afgegeven.
En was dat in 2008? Zo niet dan is dat geen argument om te zeggen "maar je had al vanaf 2008 kunnen weten dat..."

Als jij ervoor kiest zo'n mededeling te negeren omdat op dat moment de nieuwe software nog niet goed genoeg is en vervolgens ervoor kiest het de tien jaar na die mededeling te blijven negeren terwijl die software inmiddels wel degelijk is dan doe je jezelf de ellende aan waar je nu over kankert. Kom eens uit die kankermodus en kijk naar wat er gedaan moet worden.
Negeren en nog niet kunnen beginnen met migreren want het alternatief is nog benedenmaats zijn verschillende dingen.

"Gewoon de handen uit de mouwen" kan soms wel, maar soms ook echt helemaal niet, zoals verschillende commentatoren hier al opgemerkt hebben. Dat opmerken is geen kankeren, het is realiteitszin. En precies waarom "change management" zo ontzettend belangrijk is.

Ik heb er niet op gelet, maar zulke achterhaaldheids-schattingen komen van rooskleurigkijkende proponenten en gaan over de populairste publiekelijk-beschikbare dingen. "De ene die je net nodig hebt" hoeft dat niet te zijn, maar kan bijvoorbeeld bedrijfsintern zijn, of iets anders, maar is de ene die net telt voor jouw specifieke project.
Dat krijg je als je geen rekening houdt met de ontwikkelingen. De bedrijfsinterne component moet gewoon net als je andere eigen software geconverteerd worden - of zijn. Voor componenten van leveranciers die hardnekkig op 2.x blijven zitten heb je als je het goed doet al lang die leveranciers aangesproken en als er geen beweging in zit alternatieven onderzocht.
Dan krijg je dus dat "goed blijven uitkijken wie wat nu weer anders doet" bijgeteld moet worden bij de moeite die het kost om je berg ICT-code in bijgewerkte staat te houden. Makkelijk een dagtaak, en dus een argument voor complexiteitsreductie.

Het meervoud van "anecdote" is niet "data". Maargoed, een enkele codebase, waar dus tijdig iemand op gesprongen is en het kostte nog steeds anderhalf jaar. Dat kun je zien als best case. Maar dan is er nog altijd een enorme "long tail" van minder goede cases. Die allemaal als "met oogkleppen op" wegzetten is niet heel productief.
Waarmee je je kop in het zand steken tot norm verheft.
Nee. Dat is een stukje realiteitszin.

Voor mij is dat gedrag niet productief. Productief is het om op tijd te reageren op aangekondigde veranderingen zodat je niet klem komt te zitten. Je kan zwaar de schurft in hebben over dát die veranderingen eraan komen, maar met je hakken in het zand zetten los je dat niet op.
Dat laatste verzin je er zelf bij. Jou idee van "productief" is behoorlijk arbeidsintensief, dus kostbaar, en lang niet altijd haalbaar. Past nog in de "start up" waar 100+ uur per week werken de norm is, maar in een grote organisatie met veel (oude) code ga je dat gewoon niet halen. "Gewoon heel hard werken" kun je dus ook niet als redelijke oplossing voor alle gevallen aannemen.

Die conversie laat zien dat het kennelijk kan, en daar was tien jaar echt niet onvoldoende. De code waar ik mee te maken heb in Python is niet van die omvang, en ik heb gewoon met enige regelmaat gecheckt of externe libraries waar mijn code van afhangt al voor Python3 beschikbaar waren, en of er equivalente libraries waren waarop overgestapt kon worden. Met die benadering was ik in 2015 al volledig over.
Jij wel, mooi man.

Geen Python, maar ik heb zelf in een ver verleden een conversie van een grote code base (honderden mensjaren ontwikkelinspanning) naar een ander besturingssysteem en andere compiler meegemaakt. Zowel de andere compiler als verschillen in het besturingssysteem en aangeroepen aangekochte software leverden, net als nu met Python, de noodzaak op in alle sources aanpassingen te doen. Daar is toen een eigen conversieprogramma voor gemaakt, dat gaandeweg tijdens de conversie werd uitgebreid en bijgeschaafd op basis van wat men tegenkwam. Die hele conversie is toen met succes afgerond in ongeveer driekwart jaar, en het team dat de broncode converteerde bestond uit slechts drie mensen, een fractie van de ontwikkelafdeling van dat bedrijf.
Er bestaan vele bedrijven opgemaakt uit schoolklassen vol met computerprogrammerende mensen waar je in het hele bedrijf geen drie zulke mensen tegen zult komen. Een hoop van die bedrijven zou zelfs niet eens in staat zijn zulke mensen te headhunten. Oftewel, heel mooi dat het jullie wel gelukt is, maar dat is een in het verleden behaald resultaat dat geen garantie is voor de toekomst, of zelfs maar zonder meer reproduceerbaar elders.

Je kan het allemaal zo groot en zo erg mogelijk maken en daar al je energie aan verspillen, maar ik denk dat het in de meeste gevallen gewoon goed te doen moet zijn.
Dat denk jij. Ik denk dat je daar iets te makkelijke aannames over doet.
25-08-2019, 20:29 door Anoniem
Door Anoniem: Het punt was dus inderdaad dat ze dat vooral voor en vanuit eigen perspectief gedaan hebben. En dat past niet altijd bij het perspectief van de eindgebruiker. Ook al staat het er wat gechargeerd, je kan dat niet zomaar wegwuiven.
Kan je hun perspectief dan wel wegwuiven? Met welk recht van spreken kan je dat precies?

Je kan vanalles zeggen maar je hoeft niet te verwachten dat anderen onbezoldigd moeite voor jou gaan doen. Dat is wat anders.
Dat is anders precies wat je zelf luidkeels van de makers van Python aan het eisen bent.

Dan zorg je toch dat je de versie twee van die referentie-implementatie betaald nog langer in de lucht houdt, eventueel gecomplimenteerd met een betaalde overzetdienst? Lijkt me een gouden combinatie voor een consultingbedrijfje.
Het is open source, dus dat kan. De bedrijven die de ongetwijfeld dure diensten van zo'n consultingbedrijfje afnemen moeten wel bedenken dat ze daarmee uitstel van executie kopen, geen afstel. Die conversie toch maar aanpakken is vermoedelijk uiteindelijk minder duur.

Het is ook goed mogelijk dat RedHat het nog een poos blijft ondersteunen, en zowel Debian 9 (jessie) als 10 (buster) worden tot 2022 ondersteund, inclusief Python2, en die zijn ook nooit te beroerd geweest om beveiligingslekken zelf te dichten.

Dus als lange termijn belangrijk is voor je organisatie, dan is dat een punt tegen python (en nog veel meer andere taaltjes ook; php, ruby, node.js, allerlei fly-by-night andere talen en taaltjes). Als je nu concludeert dat er maar verrekte weinig taaltjes overblijven na dat filter, dat is correct.
Dat concludeer jij, maar ik niet. Ik weet dat ik in Python aanzienlijk productiever ben dan in andere talen waarin ik heb geprogrammeerd. De hoeveelheid code om iets voor elkaar te krijgen is aanzienlijk minder dan bij die andere talen en aanzienlijk overzichtelijker. Dat is goed voor de onderhoudbaarheid, die productiviteitswinst is niet eenmalig. Ik denk dat hij meer dan groot genoeg is om tegen het productiviteitsverlies van die conversie op te wegen, zeker als je bedenkt dat Python3 in deze aspecten een verbetering is ten opzichte van Python2.

En was dat in 2008? Zo niet dan is dat geen argument om te zeggen "maar je had al vanaf 2008 kunnen weten dat..."
Ja, dat was op 3 november 2008. Op 23-08-2019, 10:27 heeft iemand hierboven er al naar gelinkt, ik denk in reactie op jou. Misschien moet je die informatie even tot je laten doordringen in plaats van je energie te steken in kankeren op wat diezelfde mensen die die aankondiging publiceerden volgens jou allemaal nalaten.

"Gewoon de handen uit de mouwen" kan soms wel, maar soms ook echt helemaal niet, zoals verschillende commentatoren hier al opgemerkt hebben. Dat opmerken is geen kankeren, het is realiteitszin. En precies waarom "change management" zo ontzettend belangrijk is.
Change management op orde hebben betekent helemaal niet dat je de handen niet uit de mouwen zou kunnen steken. En ik zeg helemaal niet dat het wel goed komt als je maar zo hard mogelijk gaat werken, integendeel, ik zeg juist dat het werk beheersbaar is als je het op een verstandige manier benadert.

Waarmee je je kop in het zand steken tot norm verheft.
Nee. Dat is een stukje realiteitszin.
Als de realiteit is dat de support gaat stoppen dan getuigt het van realiteitszin om op tijd maatregelen te nemen, niet om dat na te laten.

Voor mij is dat gedrag niet productief. Productief is het om op tijd te reageren op aangekondigde veranderingen zodat je niet klem komt te zitten. Je kan zwaar de schurft in hebben over dát die veranderingen eraan komen, maar met je hakken in het zand zetten los je dat niet op.
Dat laatste verzin je er zelf bij. Jou idee van "productief" is behoorlijk arbeidsintensief, dus kostbaar, en lang niet altijd haalbaar.
Verzin ik dat er zelf bij? Het lijkt wel alsof jij volslagen incapabel bent om te bevatten dat het probleem niet weggaat als je hardnekkig volhoudt dat het niet aan jou is om er rekening mee te houden. En er komen ook geen kaboutertjes opdagen die het voor je komen oplossen. Ja, het kost geld. Het kost nog veel meer geld als je het niet doet en in een situatie belandt dat je het hals over kop toch moet doen maar geen tijd meer hebt om het goed te doen. Het is dus productiever om het op tijd en goed te doen dan om jezelf een crisis in te werken.
Past nog in de "start up" waar 100+ uur per week werken de norm is, maar in een grote organisatie met veel (oude) code ga je dat gewoon niet halen. "Gewoon heel hard werken" kun je dus ook niet als redelijke oplossing voor alle gevallen aannemen.
Als die grote organisatie het goed aanpakt kan vermoedelijk een handjevol mensen de bulk van het werk doen, in vrij beperkte tijd. Dat is precies wat ik mee heb gemaakt. Die driekwart jaar conversiewerk is gewoon op werkdagen van 9 tot 5 uitgevoerd.

Er bestaan vele bedrijven opgemaakt uit schoolklassen vol met computerprogrammerende mensen waar je in het hele bedrijf geen drie zulke mensen tegen zult komen.
Dan is dát het probleem dat die bedrijven hebben. Ze doen dingen die ze eigenlijk niet aankunnen en zijn daardoor niet weerbaar als zich iets voordoet dat even wat meer vergt. Misschien dat ze bij de Python Software Foundation, net als ik, uitgaan van een zeker niveau van professionaliteit en buiten die overgangsperiode van een luttele 10 jaar niet de incompetentieproblemen van andere organisaties voor ze op gaan lossen.
26-08-2019, 18:15 door Anoniem
Door Anoniem:
Door Anoniem: Het punt was dus inderdaad dat ze dat vooral voor en vanuit eigen perspectief gedaan hebben. En dat past niet altijd bij het perspectief van de eindgebruiker. Ook al staat het er wat gechargeerd, je kan dat niet zomaar wegwuiven.
Kan je hun perspectief dan wel wegwuiven? Met welk recht van spreken kan je dat precies?
Nouja, wat is het nut van een programmeertaal? Om ergens in een hoekje niet gebruikt te worden?

Je kan vanalles zeggen maar je hoeft niet te verwachten dat anderen onbezoldigd moeite voor jou gaan doen. Dat is wat anders.
Dat is anders precies wat je zelf luidkeels van de makers van Python aan het eisen bent.
Oh? Laat zien hoe.

Waarmee je je kop in het zand steken tot norm verheft.
Nee. Dat is een stukje realiteitszin.
Als de realiteit is dat de support gaat stoppen dan getuigt het van realiteitszin om op tijd maatregelen te nemen, niet om dat na te laten.
Hoe realistisch is het om te gaan zinnen op een conversie naar een alternatief dat nog niet eens gereleased is?

Het is mischien goed nog eens op te merken dat de neofiele programmeur hier een ander perspectief heeft dan de conservatieve productiemanager en de cynische systeembeheerder.

Verzin ik dat er zelf bij? Het lijkt wel alsof jij volslagen incapabel bent om te bevatten dat het probleem niet weggaat als je hardnekkig volhoudt dat het niet aan jou is om er rekening mee te houden.
Dat lees je er zelf in. Maar ik denk dat we wel klaar zijn hier.

Er bestaan vele bedrijven opgemaakt uit schoolklassen vol met computerprogrammerende mensen waar je in het hele bedrijf geen drie zulke mensen tegen zult komen.
Dan is dát het probleem dat die bedrijven hebben.
Dit is een algemeen probleem in de industrie: Zelfs door ondertussen leerlingen van de lagere school maar te "leren programmeren" wordt de poel met talent niet groter. Meer kindertjes leren programmeren levert niet meer echt talent op. Waarmee we moeten concluderen dat degenen die echt talent hebben toch wel in de programmeerderij terechtkomen. Alleen betekent dat dan weer niet dat ze ook zomaar voor elk bedrijf beschikbaar zijn.

Naast nog dat de mensenselectie bedroevend is, dus dat de bestaande poel niet optimaal benut wordt, wat dat "optimaal benut" dan ook moge zijn.

Dat betekent dus ook dingen voor een team van kennelijk wel echt talentvolle programmeurs dat een programmeertaal knutselt en ondertussen aannames doet over wat redelijk is om de hele installed base van de ene versie naar de andere incompatibele versie te laten springen.

Ze doen dingen die ze eigenlijk niet aankunnen en zijn daardoor niet weerbaar als zich iets voordoet dat even wat meer vergt. Misschien dat ze bij de Python Software Foundation, net als ik, uitgaan van een zeker niveau van professionaliteit en buiten die overgangsperiode van een luttele 10 jaar niet de incompetentieproblemen van andere organisaties voor ze op gaan lossen.
Welke problemen ben je dan aan het oplossen? Oh ja, die zijn we ook al tegengekomen: Het eigen gemak.
27-08-2019, 07:57 door Krakatau
Deze blijft het strijdtoneel der programmeertaal geweldig samenvatten: https://www.memecenter.com/fun/4205561/if-programming-languages-were-weapons.
27-08-2019, 08:30 door Anoniem
Door Anoniem:
Kan je hun perspectief dan wel wegwuiven? Met welk recht van spreken kan je dat precies?
Nouja, wat is het nut van een programmeertaal? Om ergens in een hoekje niet gebruikt te worden?
Nee. Maar dat impliceert niet dat een groep mensen die een programmeertaal maakt en aan de wereld ter beschikking stelt met handen en voeten gebonden is om alle gebruikers van die programmeertaal in alle omstandigheden op hun wenken te bedienen. Ze hebben het volste recht om wat ze doen op hun eigen voorwaarden te doen, zeker als ze geen contracten met die eindgebruikers afsluiten over hoe ze het doen.

Je kan vanalles zeggen maar je hoeft niet te verwachten dat anderen onbezoldigd moeite voor jou gaan doen. Dat is wat anders.
Dat is anders precies wat je zelf luidkeels van de makers van Python aan het eisen bent.
Oh? Laat zien hoe.
Je hele tirade gaat over wat de "programmeur-knutselaars" die Python maken allemaal niet niet goed doen. Wil je beweren dat je dat doet zonder dat de basis daarvoor is dat je vindt dat ze wel dingen moeten doen zoals jij vindt dat ze moeten gebeuren? Als je dat niet vindt, waar gaat die tirade dan eigenlijk over?

Hoe realistisch is het om te gaan zinnen op een conversie naar een alternatief dat nog niet eens gereleased is?
Volkomen realistisch. Je kan je afhankelijkheden inventariseren, je erop voorbereiden dat er een conversieinspanning aan zit te komen en daar rekening mee houden in je budgettering en ruimte ervoor in je planning vrijhouden. Je kan zorgen dat je organisatie actief de ontwikkeling van Python3 in de gaten houdt, dat er mensen zijn een beeld hebben van hoe groot de verschillen zijn en waar de conversieproblemen te verwachten zijn. Je kan af en toe kleine proefconversies doen van onderdelen van je systeem om een beeld te krijgen van wat de 2to3-tool (die ook al sinds 2008 bestaat) kan en niet kan. Je kan zorgen dat kennis van de extensiemogelijkheden van die tool in je organisatie aanwezig is zodat je in kan schatten of bijvoorbeeld de overstap naar een alternatieve library als onderdeel van de conversie langs die weg te automatiseren is en hoe dat zich verhoudt tot een handmatige overstap qua inspanning. Je kan al heel veel inzicht opdoen over de situatie als je nog niet weet hoe de Python3-versie waar je naar overstapt er precies uit zal zien.

Het is mischien goed nog eens op te merken dat de neofiele programmeur hier een ander perspectief heeft dan de conservatieve productiemanager en de cynische systeembeheerder.
Je hoeft niet steeds op zoek te zijn naar nieuwe dingen om rekening te houden met nieuwe dingen waarmee je nou eenmaal te maken krijgt. Er dringt nog steeds niet tot je door dat rekening houden met onvermijdelijke wijzigingen die op je afkomen keihard nodig is. Als het goed is weet ook een conservatieve productiemanager dat donders goed.

Verzin ik dat er zelf bij? Het lijkt wel alsof jij volslagen incapabel bent om te bevatten dat het probleem niet weggaat als je hardnekkig volhoudt dat het niet aan jou is om er rekening mee te houden.
Dat lees je er zelf in. Maar ik denk dat we wel klaar zijn hier.
Ik las het net weer in die "neofiele" programmeur, waar je kennelijk rekening houden met de toekomst mee verwart. Maar het is inderdaad tijd om ermee te stoppen.

Dit is een algemeen probleem in de industrie: Zelfs door ondertussen leerlingen van de lagere school maar te "leren programmeren" wordt de poel met talent niet groter. Meer kindertjes leren programmeren levert niet meer echt talent op. Waarmee we moeten concluderen dat degenen die echt talent hebben toch wel in de programmeerderij terechtkomen. Alleen betekent dat dan weer niet dat ze ook zomaar voor elk bedrijf beschikbaar zijn.
Op zich klopt dat. Ik ben het er alleen niet mee eens dat makers van bijvoorbeeld Python het blok aan hun been moeten blijven meeslepen om dat te compenseren met het eindeloos blijven ondersteunen van een verouderde versie.

Dat betekent dus ook dingen voor een team van kennelijk wel echt talentvolle programmeurs dat een programmeertaal knutselt en ondertussen aannames doet over wat redelijk is om de hele installed base van de ene versie naar de andere incompatibele versie te laten springen.
"Springen". Je doet net of ze twee seconden de tijd hebben gekregen voor de verandering. Meer dan tien jaar, weet je nog?

Welke problemen ben je dan aan het oplossen? Oh ja, die zijn we ook al tegengekomen: Het eigen gemak.
Als je dat "eigen gemak"-argument gebruikt doe het dan niet eenzijdig. De bedrijven die nu een conversieprobleem hebben hebben ook voor hun eigen gemak geautomatiseerd. Ze hadden aanzienlijk meer mensen nodig gehad en waren aanzienlijk duurder uitgeweest als ze hetzelfde werk allemaal met pen en papier moesten doen. Als je vindt dat zij een legitieme klacht hebben en dat extra conversiewerk niet zouden moeten doen, wat nog altijd aanzienlijk minder is dan hun hele hebben en houden met de hand doen, waarom is het dan niet legitiem voor de Python Software Foundation om een grens te stellen aan hoeveel werk zij doen?

Natuurlijk was de conversie aanzienlijk eenvoudiger geweest als je Python2 en Python3 moeiteloos in één Python-runtime had kunnen mengen, dat spreek ik echt niet tegen. Maar ik accepteer wel dat men bij de Python Software Foundation die keuze nou eenmaal gemaakt heeft en vind ook dat men het recht heeft om een eigen koers daarin te varen en niet verplicht is om eindeloos lang belast te worden met het onderhouden van een oude versie. Als die tien jaar niet genoeg is omdat een hoop ondernemingen verzuimen er rekening mee te houden, iets dat jij kennelijk heel verdedigbaar vindt, dan is twintig jaar ook niet genoeg, want met die mentaliteit komen ze de volgende tien jaar net zo min in beweging, en dertig jaar ook niet, want de tien jaar daarna zullen niet anders zijn.

Ik beschouw het als een externe omstandigheid die net zo hard op je afkomt als nieuwe belasting- of privacywetgeving of een grote verschuiving in de markt. Bedrijven hebben altijd al voortdurend met de meest uiteenlopende veranderingen moeten omgaan, en dat zal ook altijd zo blijven. Dat hoort erbij als je een bedrijf hebt, het woord "ondernemen" gaat niet over achterover leunen maar over actief reageren én anticiperen op veranderende omstandigheden. Eindeloos kankeren op een verandering die je niet bevalt, het negeren ervan verdedigen en het balletje neerleggen bij een externe partij die het echt niet opeens anders gaat doen staat daar lijnrecht tegenover.

Ik ga verder niet meer reageren, we draaien al lang genoeg in kringetjes rond.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.