Risposta

Storia della questione: I type hints sono apparsi in Python 3.5 (PEP 484) per supportare l'analisi statica del codice, il completamento automatico, il refactoring e la documentazione automatica. In precedenza, Python si era sempre ben comportato senza tipizzazione rigida, ma con l'aumento dei progetti e dei team, sono diventati necessari per migliorare la qualità del codice.

Problema: Le annotazioni dei tipi sono solo suggerimenti per gli sviluppatori e per strumenti esterni (mypy, Pyright, ecc.), l'interprete stesso le ignora durante l'esecuzione. Gli errori si verificano spesso se:

• Le annotazioni sono errate o non corrispondono ai tipi reali
• Le annotazioni si rompono a causa di cambiamenti dinamici dei tipi
• Errori con strutture complesse che usano i Generics (ad esempio, List[Dict[str, int]])

Soluzione: Utilizzare le annotazioni dei tipi per le funzioni e le variabili per migliorare la leggibilità, l'analisi del codice da parte dei linter e degli IDE. Non bisogna fare affidamento esclusivo sulle annotazioni: è necessaria una verifica statica dei tipi. Esempio:

def greeting(name: str) -> str:
    return f"Hello, {name}"

def sum_nums(nums: list[int]) -> int:
    return sum(nums)

Esempi più complessi utilizzano il modulo typing:

from typing import List, Dict, Optional

def process(data: List[Dict[str, Optional[int]]]) -> None:
    ...

Caratteristiche principali:

• Le annotazioni non influenzano il comportamento del codice durante l'esecuzione
• Combinare sempre i type hints con un analizzatore esterno
• Per strutture complesse, utilizzare typing.

Domande ingannevoli.

L'interprete Python gestisce i tipi dalle annotazioni durante l'esecuzione?

No. Le annotazioni sono accessibili tramite __annotations__, ma non controllano il comportamento durante l'esecuzione.

È possibile utilizzare variabili senza annotazioni in funzioni annotate?

Sì. Le annotazioni non sono obbligatorie, ma la loro assenza può confondere.

È possibile ridefinire il tipo di una variabile dopo l'annotazione?

Sì, ma questo viola il principio dell'analisi statica e ostacola i linter. Meglio evitare:

x: int = 5
x = 'stringa'  # Il linter darà un avviso, ma il codice verrà eseguito.

Errori tipici e anti-pattern

• Non corrispondenza tra il tipo implementato e il valore nell'annotazione
• Non utilizzo di un analizzatore esterno (linters, mypy)
• Type hints troppo complessi o ridondanti che rendono difficile la lettura

Esempio di vita reale

Caso negativo: Si annota una funzione, ma il tipo restituito è diverso da quello in annotazione a causa della modifica della logica della funzione. Punti positivi:

• Il codice viene eseguito Punti negativi:
• È facile ottenere un bug difficile da testare e da individuare

Caso positivo: Tutte le funzioni e i dati sono annotati, il progetto viene controllato da mypy durante CI/CD. Punti positivi:

• Alta manutenibilità e leggibilità del codice Punti negativi:
• Richiede tempo per essere implementato e per formare il team