Refactor di liste in Python rompe il chiamante senza errori

Cambiare rows.sort() in rows = sorted(rows) e vedere i test verdi può mandare in produzione un bug silenzioso: il chiamante continua a leggere la lista vecchia¹.

Il post spiega che la mutazione in-place è spesso parte silenziosa del contratto di un modulo. Molti test verificano il valore di ritorno di una funzione. Quasi nessuno controlla se la lista del chiamante è cambiata sotto i suoi piedi. Così, sostituire una mutazione con una copia lascia verde la suite. In produzione, però, il codice legge ancora l’oggetto originario, nell’ordine originario¹.

Il punto è l’aliasing, non la logica. Un chiamante passa una lista. La funzione la modifica e restituisce None. Il chiamante non legge il return, legge la sua variabile più tardi. Questo è un contratto reale che vive fuori dalle asserzioni. Arriva il refactor: ora la funzione restituisce una lista nuova. I test sul valore di ritorno passano. Il chiamante conserva il suo oggetto stantio. Nessuna eccezione. Nessun log di errore. Il danno è silenzioso perché la firma non è cambiata. Quindi il varco deve registrare le mutazioni, non solo gli output¹.

L’esempio più chiaro è l’ordinamento. rows.sort() muta la lista ricevuta. rows = sorted(rows) restituisce una lista ordinata nuova. Se il chiamante si aspetta che la propria lista sia stata riordinata in loco, il refactor spezza quell’aspettativa. Un test che guarda solo il return non se ne accorge, la produzione sì¹.

Per proteggere questa cucitura tra copia e mutazione, l’autore invita a “congelarla” prima di toccare il corpo della funzione. Serve rendere visibili le mutazioni come parte del contratto, non basta verificare l’output¹.

La proposta concreta è un “mutation ledger”. Una piccola sonda avvolge la funzione. Scatta uno snapshot profondo di ogni argomento prima della chiamata. Dopo l’esecuzione, calcola una differenza per ciascun argomento e aggiunge una riga JSON per ogni invocazione. In questo modo, chiamata per chiamata, resta traccia di ciò che è cambiato sugli argomenti passati¹.

Il post include un modulo di esempio, mutation_probe.py. Importa copy, functools e json. La funzione interna _snapshot prova a eseguire una deepcopy dell’argomento, così da congelare lo stato pre-chiamata. Dopo la chiamata, il probe confronta gli argomenti e appende il risultato come singola riga JSON per ogni invocazione¹.

Questa traccia di mutazioni espone il confine tra alias condivisi e oggetti nuovi. Il ledger registra se un argomento è cambiato durante la chiamata. Se un refactor sostituisce una mutazione con una copia, la differenza tra prima e dopo lo rende evidente anche quando i test di ritorno restano verdi¹.

L’implicazione pratica è chiara: quando una funzione può mutare i propri argomenti, il contratto non vive solo nel valore di ritorno. Va congelato e reso osservabile. Prima del refactor, costruire un registro delle mutazioni riduce il rischio di rompersi in silenzio pur con la suite che passa¹.