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.

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...

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.

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...

Python 2 is nog steeds de default op Ubuntu...
Zal ook niet helpen..

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.

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.

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....

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.

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.


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.


Dat is eigenlijk veel te laag geschat. We hebben nog veel oudere code die nog in productie is.

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 maar hoe je het bekijkt. Tot op het punt dat "3" wel "python's zelfmoordbriefje" genoemd is, en niet zonder reden.

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.

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.

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


Tja, als je als organisatie Windows gebruikt dan kan ik je nog maar met moeite serieus nemen. Wat verwacht je nou daarmee?

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.

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.

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:


(bron: https://adtmag.com/articles/2019/01/08/tiobe-jan-2019.aspx)

De leeftijd van code is iets anders dan de tijd die je nodig hebt voor een conversie.

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.

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.

Zit je nou het probleem van slecht management op het bordje van een programmeertaal te leggen?

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.

Dat is precies het punt dat ik maak.
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

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?

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.

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.

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.

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.

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.

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.

Met een hoop schuld op de eindgebruiker z'n bordje zonder naar de programmeur-knutselaar te willen kijken.

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.

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.

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?

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.

Niet iedere 10 jaar, het is één keer gebeurd met een transitieperiode van ruim 10 jaar. Dat is iets volkomen anders.

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 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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.)

Die houden we even aan.

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.

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!

En was dat in 2008? Zo niet dan is dat geen argument om te zeggen "maar je had al vanaf 2008 kunnen weten dat..."

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.

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.

Nee. Dat is een stukje realiteitszin.

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.

Jij wel, mooi man.

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.

Dat denk jij. Ik denk dat je daar iets te makkelijke aannames over doet.

Kan je hun perspectief dan wel wegwuiven? Met welk recht van spreken kan je dat precies?

Dat is anders precies wat je zelf luidkeels van de makers van Python aan het eisen bent.

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.

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.

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.

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.

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.

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.
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.

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.

Nouja, wat is het nut van een programmeertaal? Om ergens in een hoekje niet gebruikt te worden?

Oh? Laat zien hoe.

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.

Dat lees je er zelf in. Maar ik denk dat we wel klaar zijn hier.

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.

Welke problemen ben je dan aan het oplossen? Oh ja, die zijn we ook al tegengekomen: Het eigen gemak.

Deze blijft het strijdtoneel der programmeertaal geweldig samenvatten: https://www.memecenter.com/fun/4205561/if-programming-languages-were-weapons.

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 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?

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.

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.

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.

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.

"Springen". Je doet net of ze twee seconden de tijd hebben gekregen voor de verandering. Meer dan tien jaar, weet je nog?

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.