Analisti Pandas Freelance Italiani

Perché non continuare a usare Excel?

Per tre ragioni che si scoprono quasi sempre troppo tardi, e nessuna riguarda la potenza del foglio di calcolo.

Ripetibilità: un report costruito a mano dipende da chi lo fa. Uno script produce lo stesso risultato ogni volta, e se cambia la logica la si cambia in un punto solo.
Tracciabilità: in un foglio non si sa chi ha modificato quella cella e perché. Uno script sta in un repository con la storia delle modifiche.
Volumi: oltre qualche centinaio di migliaia di righe il foglio di calcolo diventa lento o si rifiuta di aprire il file.

Il percorso che funziona non è abolire Excel, che resta ottimo per guardare i dati: è smettere di usarlo come procedura. Lo script legge e scrive file Excel, così chi li usa non cambia abitudini.

È vero che la versione 3 richiede PyArrow?

No, ed è l'informazione sbagliata più diffusa su questo argomento. Era il piano originale, ma è stato rinviato: pandas 3 non ha PyArrow fra le dipendenze obbligatorie.

Come stanno le cose: PyArrow è facoltativo e serve per alcuni formati di file e per il nuovo tipo stringa quando è installato; in sua assenza si usa un'alternativa interna.
Perché conta: l'installazione resta leggera, cosa rilevante in ambienti con vincoli di spazio o di certificazione delle dipendenze.
Cosa verificare comunque: se lavori con file Parquet, PyArrow ti serve e va installato esplicitamente.

Il nostro codice pandas ha smesso di funzionare dopo un aggiornamento: perché?

Probabilmente per uno dei due cambiamenti introdotti dalla versione 3, entrambi voluti e documentati.

La modifica a catena non funziona più: il modo in cui molti aggiornavano una parte di tabella in due passaggi è stato eliminato. Va riscritto usando l'accesso esplicito per righe e colonne. In compenso è sparito il famigerato avviso che nessuno sapeva mai come interpretare.
Le stringhe hanno un tipo dedicato: prima una colonna di testo risultava di tipo generico, ora ha un tipo proprio. Il codice che controllava esplicitamente il vecchio tipo smette di riconoscerla.

È un lavoro di adeguamento circoscritto e meccanico, che conviene affrontare con qualche test di verifica: su script di produzione sono tipicamente poche giornate.

Quanto si risparmia davvero automatizzando un report?

Il conto si fa in modo semplice e di solito convince da solo.

Prendi il tempo mensile che una persona dedica oggi a costruire quel report, moltiplicalo per dodici e per il costo orario.
Aggiungi il costo degli errori: in un processo manuale ripetuto, prima o poi un dato viene copiato male, e il costo è la decisione presa su quel numero.
Sottrai il costo dello sviluppo, che per un report ricorrente è tipicamente di pochi giorni, più una manutenzione leggera quando cambiano le fonti.

Nei casi che incontriamo il ritorno arriva entro pochi mesi, e il beneficio nascosto è che il processo smette di dipendere da una persona sola.

Fino a che volumi si può arrivare?

Pandas lavora in memoria, quindi il limite è la memoria della macchina. Nella pratica si gestiscono comodamente milioni di righe; oltre, le strade sono tre.

Lavorare a blocchi: leggere il file a pezzi ed elaborarlo in sequenza. Spesso basta.
Spostare il lavoro nel database: far fare le aggregazioni pesanti al database e portare in Python solo il risultato. È quasi sempre la soluzione migliore quando i dati sono già lì.
Passare a uno strumento pensato per volumi maggiori, se le prime due non bastano.

Un consulente onesto propone le prime due prima di suggerire un cambio di tecnologia.