Scrivere codice Pythonic: indentazione, moduli, stile

Hai mai riaperto un tuo script dopo sei mesi e pensato «ma chi ha scritto questa roba?» — salvo poi ricordare che eri tu? Oppure hai copiato codice da due tutorial diversi e il risultato sembra scritto da due persone che non si sono mai parlate? È il momento di parlare di stile. Non è estetica fine a se stessa: in Python lo stile è parte del linguaggio, al punto che esiste un aggettivo apposta — Pythonic — per il codice che sfrutta il linguaggio come è stato pensato. In questo tutorial vediamo le tre gambe dello sgabello: indentazione, convenzioni di stile e moduli. E lo facciamo nel modo più concreto possibile: stesso programma, due stili.

L’indentazione non è decorazione

Se vieni da altri linguaggi, sai che i blocchi di codice si delimitano con parentesi graffe e l’indentazione è una cortesia per chi legge. In Python no: l’indentazione È la sintassi. Un blocco inizia dopo i due punti e comprende tutte le righe rientrate dello stesso numero di spazi. Pensa all’indice di un libro: i capitoli a filo del margine, i paragrafi rientrati sotto il loro capitolo. Sposti un paragrafo a filo del margine e diventa un capitolo — cambia il significato, non solo l’aspetto. In Python è identico:

saldo = 120

if saldo > 100:
    print("Saldo alto")          # dentro l'if: eseguita solo se vero
    print("Puoi permettertelo")  # ancora dentro l'if
print("Controllo finito")        # fuori dall'if: eseguita SEMPRE

Sposta l’ultima print quattro spazi a destra e il programma cambia comportamento, senza che nessun errore te lo segnali. La convenzione universale è 4 spazi per livello (mai il tasto Tab misto a spazi: è la ricetta per l’errore TabError: inconsistent use of tabs and spaces, il pianto di benvenuto di ogni principiante). Buone notizie: qualunque editor moderno, VS Code incluso, converte Tab in 4 spazi da solo.

Stesso codice, due stili

Veniamo al cuore del tutorial. Problema semplice: date le temperature della settimana, trovare quelle sopra la media. Prima versione — corretta, funzionante, e scritta come la scriverebbe chi traduce mentalmente da un altro linguaggio:

# versione_goffa.py — funziona, ma rema contro il linguaggio
temperature = [12.5, 15.0, 9.8, 21.3, 18.6]

# calcolo della media "a mano", con indici
somma = 0
for i in range(0, len(temperature)):
    somma = somma + temperature[i]
media = somma / len(temperature)

# selezione dei valori sopra la media, ancora con indici
sopra_media = []
for i in range(0, len(temperature)):
    if temperature[i] > media:
        sopra_media.append(temperature[i])

print(sopra_media)   # [21.3, 18.6]

Ora la versione Pythonic. Se non ricordi cos’è una list comprehension, ti basta sapere che è un modo per costruire una lista in una riga, leggendola quasi come una frase italiana: «prendi t per ogni t in temperature, se t è maggiore della media».

# versione_pythonic.py — stesso identico risultato
temperature = [12.5, 15.0, 9.8, 21.3, 18.6]

media = sum(temperature) / len(temperature)
sopra_media = [t for t in temperature if t > media]

print(sopra_media)   # [21.3, 18.6]

Quattordici righe contro sei, tre variabili di appoggio contro zero, e — soprattutto — la seconda versione si legge ad alta voce. Nota il trucco di fondo: in Python non si itera per indice, si itera direttamente sugli elementi (for t in temperature). È come sfogliare un album di foto: guardi le foto una per una, non dici «ora guardo la foto in posizione 3». Quando l’indice serve davvero c’è enumerate, che vedremo tra qualche tutorial.

Il codice si scrive una volta e si legge cento: ottimizzare la lettura, non la scrittura, è l’idea che regge tutto lo stile Python.

PEP 8: il codice della strada

Le convenzioni di stile di Python sono scritte in un documento ufficiale, il PEP 8 («Python Enhancement Proposal» numero 8). È il codice della strada del linguaggio: puoi tecnicamente guidare contromano in un parcheggio vuoto, ma se tutti seguono le stesse regole il traffico scorre — e il codice degli altri ti sembra subito familiare. Le regole che coprono il 90% dei casi:

• Nomi: variabili e funzioni in snake_case minuscolo (tasso_interesse, calcola_media), classi in PascalCase (RegressioneLineare), costanti in MAIUSCOLO (SOGLIA_MAX). E nomi che dicono cosa contengono: temperature batte lst sempre.
• Spazi: uno attorno agli operatori (a = b + 1, non a=b+1), nessuno dentro le parentesi.
• Righe corte: massimo 79 caratteri per PEP 8, ma oggi quasi tutti i team si assestano su 88–99. L’importante è non dover scorrere in orizzontale.
• Due righe vuote tra una funzione e l’altra, per far respirare il file.

La parte migliore? Non devi memorizzare niente: esistono strumenti che controllano e correggono per te. Nel 2026 lo standard è Ruff, che fa sia da guardia (linter) sia da carrozziere (formatter), ed è velocissimo:

# Nell'ambiente virtuale del progetto (vedi tutorial precedente)
pip install ruff

# Segnala i problemi di stile e gli errori comuni
ruff check versione_goffa.py

# Riformatta il file secondo le convenzioni, automaticamente
ruff format versione_goffa.py

In VS Code puoi installare l’estensione «Ruff» e attivare il formato al salvataggio: da quel momento lo stile smette letteralmente di essere un tuo problema.

Moduli: un cassetto per ogni cosa

Quando lo script supera le cento righe, tenerlo in un unico file è come tenere posate, bollette e cacciaviti nello stesso cassetto: tutto c’è, niente si trova. Un modulo in Python è semplicemente un file .py le cui funzioni puoi importare da altri file. Creiamo un cassetto per le statistiche:

# statistiche.py — il nostro primo modulo
def media(valori):
    """Media aritmetica di una sequenza di numeri."""
    return sum(valori) / len(valori)


def sopra_media(valori):
    """Restituisce i valori maggiori della media."""
    m = media(valori)
    return [v for v in valori if v > m]

# analisi.py — il programma principale, nella stessa cartella
from statistiche import sopra_media

temperature = [12.5, 15.0, 9.8, 21.3, 18.6]
print(sopra_media(temperature))   # [21.3, 18.6]

Due regole di stile sugli import: vanno tutti in cima al file (prima la libreria standard, poi le librerie esterne, poi i tuoi moduli), e mai from statistiche import * — l’asterisco rovescia l’intero cassetto sul tavolo e non sai più da dove arriva ogni nome. Quando nei prossimi tutorial scriverai import numpy as np, starai usando esattamente questo meccanismo: NumPy è «solo» un cassetto molto ben organizzato scritto da altri.

Quando il Pythonic diventa vezzo

Onestà intellettuale, come sempre: «Pythonic» non significa «tutto in una riga». Una comprehension annidata su tre livelli con due condizioni è tecnicamente elegante e praticamente illeggibile — a quel punto un buon vecchio ciclo for esplicito è la scelta giusta. Lo stesso PEP 8 lo dice nella sua regola più citata: le linee guida servono alla leggibilità, e sapere quando violarle fa parte del mestiere. Il test pratico che uso io: se devi rileggere la riga due volte per capirla, riscrivila più lunga. Il tuo io tra sei mesi ringrazierà.

Due programmi, un solo risultato: la versione a indici e quella Pythonic producono lo stesso output, ma solo una delle due si rilegge volentieri tra sei mesi.

Prova tu

Prendi questo frammento volutamente goffo e riscrivilo in stile Pythonic (ti serviranno una comprehension e il metodo .upper() delle stringhe):

# Da rifattorizzare: mette in maiuscolo i nomi più lunghi di 3 lettere
nomi = ["ada", "guido", "grace", "tim"]
risultato = []
for i in range(0, len(nomi)):
    if len(nomi[i]) > 3:
        risultato.append(nomi[i].upper())
print(risultato)

Quando la tua versione produce ['GUIDO', 'GRACE'], passala a ruff check e guarda se trova ancora qualcosa da ridire. Bonus: esegui import this nell’interprete Python e leggi lo «Zen of Python» — 19 aforismi che riassumono tutto questo tutorial in venti secondi.

Per approfondire: il testo integrale del PEP 8 (si legge in mezz’ora) e, quando ti sentirai pronto per il livello successivo, Fluent Python di Luciano Ramalho — il libro che trasforma chi «scrive in Python» in chi «pensa in Python».