Chi usa Python da un po’ lo sa: le versioni si susseguono con un ritmo piuttosto regolare: 3.10, 3.11, 3.12, 3.13… e ogni anno qualcuno nella community si ritrova a chiedersi: "Aspetta… ma la 3.11 è uscita prima dopo o durante il 2022?"

Per evitare questi piccoli drammi matematici, nella comunità Python è comparsa una proposta interessante: cambiare il sistema di numerazione delle versioni. L’idea arriva dalla PEP 2026, che suggerisce di adottare il Calendar Versioning (CalVer).

Tradotto: smettiamo di contare e usiamo direttamente l’anno.

Ma come funzionerebbe? Invece delle classiche versioni: Python 3.12, Python 3.13, Python 3.14 ... potremmo avere qualcosa del tipo:
-- Python 3.26 → rilasciato nel 2026
-- Python 3.27 → rilasciato nel 2027
-- Python 3.28 → rilasciato nel 2028

Quindi niente più dubbi esistenziali: se vedi Python 3.26, sai immediatamente che arriva dal 2026.
Il motivo è semplice: rendere le versioni più intuitive da capire. Chi lavora in azienda o gestisce infrastrutture spesso si trova a chiedersi:
-- questa versione è recente?
-- è ancora supportata?
-- devo aggiornare ... ieri?

Con una numerazione basata sull’anno, la risposta diventerebbe molto più immediata.

Se ti stai preoccupando: no, Python non diventerà improvvisamente Python 2026 Ultra Mega Edition seguita da Python 2027 Alabarda Spaziale Edition.Il ciclo di rilascio rimarrebbe lo stesso:
-- una nuova versione ogni anno
-- circa 5 anni di supporto

Cambierebbe solo il numero stampato sulla scatola. Come ogni proposta che riguarda Python, anche questa ha già acceso un bel po’ di discussioni. C’è chi pensa che sia: "Più chiaro, più moderno, più facile da gestire" e chi invece dice: "Abbiamo già imparato a contare fino a 3.14, non fatemi ricominciare."

Per ora la proposta è ancora in discussione, quindi non è certo che vedremo davvero Python 3.26 nei prossimi anni.

Nel frattempo… Una cosa però è sicura: che si chiami Python 3.15 o Python 3.26, continueremo comunque a fare quello che facciamo sempre:
-- scrivere codice
-- installare dipendenze
-- ...e litigare con gli ambienti virtuali.
La vera "tradizione" Python non cambia mai.