Python nel 2026: cos'è cambiato, cos'è stabile, cosa sta arrivando

Benvenuto alla prima lezione del corso Python Fundamentals. Sessanta lezioni, due a settimana, in uscita ogni martedì e venerdì da adesso fino a giugno. Alla fine avrai scritto una bella quantità di Python, l’avrai rotto in modi interessanti, l’avrai aggiustato, avrai imparato la storia di testing e packaging, e avrai attraversato abbastanza dell’ecosistema che parole come pyproject.toml, pytest, pyright, asyncio e uv ti sembreranno vecchi amici, non miniature di YouTube.

Questo non è un corso “impara a programmare da zero”. Si dà per scontato che tu abbia scritto qualcosa in qualche linguaggio prima d’ora: forse JavaScript all’università, forse un po’ di bash al lavoro, forse uno script SQL che a un certo punto si è ritrovato un “If” e una regex e un giorno è diventato un programma. Se non hai mai programmato niente puoi comunque seguirlo, ma aspettati di passare del tempo a colmare in parallelo i concetti di base (variabili, cicli, funzioni) sui quali noi non ci soffermeremo. Su cosa ci soffermeremo: come scrivere Python nel modo in cui Python moderno viene davvero scritto nel 2026, che è significativamente diverso da come si scriveva anche solo cinque anni fa.

Prima di toccare codice, mappiamo il territorio. Cos’è Python nel 2026, quale versione dovresti davvero installare, e quali dei cambiamenti degli ultimi sei anni contano in una giornata normale di lavoro?

Lo stato del linguaggio, maggio 2026

Python 3.13 è la release stabile attuale. È uscito a ottobre 2024 ed è quello che quasi ogni tutorial recente, libreria e immagine Docker base prende come riferimento. Python 3.14 è in sviluppo ed è previsto per ottobre 2026, con le solite beta nel corso dell’estate. Quando il corso finirà vedrai atterrare i primi release candidate della 3.14. Per tutto il corso punteremo alla 3.13; nulla di quello che faremo si romperà sulla 3.14.

Python 2 è morto nel 2020. Se qualcuno ti dice che “scrive ancora un po’ di Python 2”, annuisci con compassione e vai oltre. Non c’è più. La migrazione è finita. Sei anni di lutto post-funerale sono abbastanza.

Python da 3.0 a 3.7 sono anch’essi deprecati e non supportati. Se ti ritrovi su un sistema con la 3.6 o la 3.7, stai facendo archeologia di manutenzione, e dovresti iniziare capendo come installare un interprete moderno accanto senza rompere il Python di sistema. (Lo vedremo nel dettaglio nella lezione 4.)

Python da 3.8 a 3.12 sono ancora ampiamente in giro. La 3.10 e la 3.11 in particolare sono ovunque: Ubuntu 22.04 LTS è uscita con la 3.10, Ubuntu 24.04 LTS con la 3.12, e tanti portatili aziendali hanno ancora quello che il sistema operativo gli ha dato. Devi sapere che la sintassi che useremo punta alla 3.10 come minimo realistico. Più vecchio di così e dovrai riscrivere qualche esempio.

Quindi: installa la 3.13, scrivi codice che gira sulla 3.10+, non perdere il sonno per le versioni precedenti, a meno che il lavoro non te lo richieda.

Cos’è cambiato e vale la pena conoscere

Sei anni di release di Python, distillati nelle cose che hanno davvero cambiato il modo in cui si scrive Python da lavoro.

Pattern matching (3.10). Il costrutto match / case. Sembra uno switch dei linguaggi della famiglia C ma è significativamente più potente: destruttura, fa match su tipi e forme, e si integra con dataclass e named tuple. Alcuni ne abusano, altri fanno finta che non esista. Sbagliano entrambi. Lo vediamo per bene nella lezione 3.

L’operatore di unione | per i tipi (3.10). Una volta scrivevi Optional[int] o Union[int, str]. Ora è int | None e int | str. Più pulito, nessun import. I type checker lo adorano. Usalo. Lezione 2 ci entra dentro.

Messaggi d’errore migliori (3.11). Il traceback ora punta alla sotto-espressione esatta che è esplosa, non solo alla riga. Se sei mai rimasto a fissare un KeyError su una riga con cinque lookup di dizionario chiedendoti quale fosse il colpevole, questo singolo cambiamento ti fa risparmiare ore al mese. È silenzioso, è gratis, funziona e basta.

CPython più veloce (3.11+). Il progetto “Faster CPython”, guidato da Guido e Mark Shannon, ha portato un bel po’ di velocizzazioni dell’interprete nella 3.11, altre nella 3.12, e un compilatore JIT opt-in nella 3.13. I workload reali tipicamente vedono un 10-25% di velocizzazione passando dalla 3.10 alla 3.13 senza modifiche al codice. Il JIT nella 3.13 è opt-in e sperimentale: lo compili con --enable-experimental-jit e fai benchmark prima di fidartene in produzione. Per la 3.15 sarà probabilmente il default e ci dimenticheremo tutti che la transizione è avvenuta.

Nuova sintassi per i tipi (3.12). PEP 695 ha introdotto un modo più pulito per dichiarare tipi generici e alias di tipo:

# Vecchia (funziona ancora)
from typing import TypeVar
T = TypeVar("T")

def first(items: list[T]) -> T:
    return items[0]

# Nuova, 3.12+
def first[T](items: list[T]) -> T:
    return items[0]

type Json = dict[str, "Json"] | list["Json"] | str | int | float | bool | None

La maggior parte dell’ecosistema è ormai passata a questa. La useremo dalla lezione 2 in avanti.

Build free-threaded (3.13, sperimentale). Questa è quella grossa in astratto: una build di Python senza il Global Interpreter Lock. Il GIL è il lock che ha impedito il vero parallelismo nel codice puro Python dal 1992. PEP 703 è stato approvato, e la 3.13 distribuisce una build free-threaded opzionale (python3.13t). In questo momento, a maggio 2026, è ancora sperimentale, le librerie sono ancora in fase di audit per la thread-safety, e non dovresti far girare workload di produzione su di essa a meno che tu non abbia misurato con molta attenzione. Ma funziona, è reale, e passerà da sperimentale a stabile nel giro delle prossime due o tre release. L’era del “Python non sa fare parallelismo CPU-bound” sta finendo. Lo toccheremo brevemente nel modulo 8 (concorrenza).

asyncio arrivato a maturità (tutto a partire dalla 3.7). async/await ha smesso di essere controverso. Ogni framework web rilevante, ogni driver di database degno di essere usato, ogni SDK cloud ha ora una storia async funzionante. Il modulo 8 di questo corso è dedicato a questo.

Lo spostamento dell’ecosistema che devi davvero conoscere

Le feature del linguaggio sono facili da riassumere. Il cambiamento più grosso degli ultimi due anni è lo spostamento del tooling, ed è quello che davvero influenza come passerai la tua giornata.

Il packaging viene mangiato da uv. Per circa vent’anni la risposta a “come installo un pacchetto Python” è stata pip install. La risposta a “come lo isolo dal Python di sistema” era python -m venv. La risposta a “come faccio il lock delle dipendenze” era pip-tools o poetry o pipenv a seconda dell’anno in cui ti sei laureato. Era un casino.

Nel 2024 una società chiamata Astral (gli stessi dietro ruff) ha rilasciato uv, scritto in Rust, che fa tutto quanto sopra (e sostituisce pyenv per installare gli interpreti) in un unico binario, all’incirca 10-100 volte più veloce di pip. A fine 2025 era diventato il default nelle aziende Python serie per i progetti nuovi. A maggio 2026 una macchina di sviluppo Python configurata da zero è, sempre più spesso, solo uv e un editor.

Installeremo uv nella lezione 4 e lo useremo per il resto del corso. Se hai usato pip e venv prima, la memoria muscolare si trasferisce: digiti uv invece di python -m venv e pip install, e tutto è più veloce. Se non hai mai usato nessuno dei due, ancora meglio: imparerai prima il modo moderno e non dovrai disimparare quello vecchio.

pip, virtualenv e poetry non vanno da nessuna parte. I progetti esistenti li usano ancora. Continuerai a incontrare file requirements.txt, pyproject.toml e Pipfile.lock in giro per anni. Vedremo cos’è ognuno e come gestirli. Ma per i progetti nuovi, nel 2026, uv è il default.

Linting e formattazione consolidati in ruff. Stessa azienda. Stessa velocità Rust. ruff ha sostituito flake8, pylint (in parte), isort e black con un unico tool che gira a ogni salvataggio ed è troppo veloce perché te ne accorga. Se entro la lezione 8 di questo corso il tuo editor non sta facendo girare ruff al salvataggio, c’è qualcosa che non va.

Type checking: pyright ha mangiato il pranzo a mypy. Esistono entrambi, funzionano entrambi. mypy (l’originale, da Dropbox/Guido) è più configurabile e ha opinioni leggermente diverse sui casi limite. pyright (da Microsoft, scritto in TypeScript, incluso in VS Code via l’estensione Pylance) è significativamente più veloce ed è quello su cui viene controllato la maggior parte del codice nuovo. Se usi VS Code o Cursor, stai usando pyright che tu te ne sia accorto o no. Vedremo entrambi, ma il default in questo corso è pyright.

Gli assistenti AI fanno parte del toolchain ora. Copilot, Claude, Cursor: far finta che non esistano non è una posizione seria nel 2026. Nella lezione 2 parliamo di come scrivere codice in modo da renderli davvero utili (suggerimento: type hints), e più avanti nel corso parliamo di quando i loro suggerimenti tendono a essere sbagliati (in larga parte: tutto ciò che coinvolge comportamenti async sottili, tutto ciò che coinvolge il data layer della tua azienda specifica, e tutto ciò in cui inventano con sicurezza una libreria che non esiste).

”Python è lento”: affrontiamolo una volta, poi andiamo avanti

Ti sentirai dire, per sempre, che Python è lento. Non è sbagliato, esattamente, ma è la cornice sbagliata.

Python è lento sul calcolo CPU-bound in un loop stretto in puro Python. Un ciclo for che fa aritmetica in puro Python è circa 50 volte più lento dell’equivalente C. È un fatto reale e non è cambiato sostanzialmente.

Ma quasi nessun lavoro Python reale è quello. I lavori Python reali fanno questo tipo di cose:

Ricevere una richiesta HTTP, interrogare un database, formattare JSON, restituire una risposta. Il collo di bottiglia è il round-trip al database e la rete. L’overhead Python è nel rumore.
Leggere un file Parquet con polars o pyarrow, trasformare alcune colonne, scriverlo. Il calcolo vero gira in Rust o C++ chiamato da un sottile strato di orchestrazione Python. L’overhead Python è nel rumore.
Allenare un modello di machine learning con pytorch. La matematica gira su GPU in CUDA. Python è il direttore d’orchestra; non è nell’orchestra.
Incollare insieme tre API SaaS. Il collo di bottiglia è la latenza HTTP. L’overhead Python è nel rumore.

Dove Python è davvero la risposta sbagliata: motori di gioco real-time, codice numerico in hot path senza numpy/torch/jax, sistemi embedded con kilobyte di RAM, e quel tipo di trading ad alta frequenza dove un microsecondo ti costa un milione di dollari. Per tutto il resto, il lavoro che fa la maggior parte di noi, Python è abbastanza veloce, sta diventando più veloce a ogni release, e il guadagno di produttività ripaga il costo a runtime cento volte.

Questa è l’ultima volta che ne discutiamo. Se qualcuno in una code review ti dice “Python è lento, dovresti riscriverlo in Go”, chiedigli prima un benchmark. Quasi mai lo fanno.

Cosa sta arrivando nel resto del corso

Dieci moduli, all’incirca:

Python nel 2026 (sei qui): panoramica del linguaggio, setup dell’ambiente, il toolchain moderno.
Sintassi e tipi: variabili, controllo di flusso, funzioni, type hints, i nuovi generics.
Strutture dati: list, dict, set, tuple, dataclass, comprehension, quando ricorrere a ognuna.
Iteratori, generators e il protocollo di iterazione: la sala macchine di Python; capire questo cambia tutto.
Python orientato agli oggetti: classi, ereditarietà, dunder method, protocols, la storia delle dataclass.
Errori, logging e debugging: eccezioni, logging, pdb, profiling, come si fa fatto bene.
Tour della standard library: pathlib, datetime, collections, itertools, functools, subprocess, json, il modulo os.
Concorrenza: thread, processi, asyncio, Python free-threaded, quando usare cosa.
Testing e packaging: pytest, fixture, mocking, pyproject.toml, pubblicazione su PyPI, semantic versioning.
Un progetto reale, dall’inizio alla fine: costruiamo una piccola ma realistica app CLI, con test, tipi, una pipeline CI e una release. Le ultime dieci lezioni.

La lezione 2 parte con l’argomento poco sexy ma critico che ogni codebase Python moderna ormai si aspetta: i type hints. Non sono più opzionali, anche se il runtime continua a fingere che lo siano.

Letture di approfondimento

La documentazione ufficiale di Python: la tua base.
What’s New in Python 3.13: le release notes sono sorprendentemente leggibili.
PEP 703 - Making the GIL Optional in CPython: la proposta di free-threading.
Il blog di Astral: per stare al passo con uv e ruff.

Ci vediamo venerdì per i type hints.