Da SAS a Python: quanto costa davvero

La maggior parte dei risultati di questa ricerca sono strumenti che producono Python a partire dal sorgente SAS, e diversi lo fanno bene. Questa pagina parte un passo prima: se lo spostamento ha senso per la vostra base di codice, quanto costa verificare il risultato e cosa fare quando la risposta è no.

La risposta breve

Le strade per uscire da una base di codice SAS sono quattro, non due: affidarla a uno strumento automatico, riscriverla a mano, eseguire i programmi SAS così come sono su qualcosa che non è SAS, oppure lasciarla stare. Quale sia quella giusta dipende quasi solo da due domande: quanto codice c'è e se qualcuno deve riprodurre i risultati prodotti in passato. Tutto quello che segue è il costo di ciascuna strada.

Quando Python è la risposta giusta

Python è la destinazione migliore più spesso di quanto una pagina come questa di solito ammetta. Quattro condizioni rendono la scelta netta: la base di codice è abbastanza piccola perché una persona la legga in una settimana, il team scrive già Python ogni giorno, l'analisi va comunque rifatta e nulla a valle pretende che i numeri nuovi coincidano esattamente con quelli vecchi. Quando valgono tutte e quattro, riscrivere costa meno di qualunque strato di compatibilità, e resta codice che il team può mantenere senza portarsi dietro un secondo linguaggio.

Quattro strade e quanto costa ciascuna

Ogni opzione qui è la risposta giusta per qualcuno. Nessuna è senza costo, e la parte cara non è mai la sintassi.

Un convertitore automatico

Strumenti web, servizi di fornitori e grandi modelli linguistici prendono il sorgente .sas e restituiscono Python, di solito mappando i passi DATA su pandas e le procedure più comuni su statsmodels o scikit-learn. Per qualche centinaio di righe di manipolazione dati lineare è una scorciatoia vera, e dà un punto di partenza leggibile in pochi minuti. Il conto arriva dopo: ogni riga dell'output va letta da qualcuno che conosce entrambi i linguaggi.

Una riscrittura a mano

Qualcuno legge il programma SAS, capisce cosa doveva fare e lo scrive in Python. Parte più lentamente ed è l'unica strada che finisce con codice fatto come Python e non come SAS travestito. I team che due anni dopo sono ancora contenti di Python ci sono arrivati quasi sempre così, tenendo il vecchio programma in funzione accanto finché i numeri non tornavano.

Eseguire i programmi così come sono — 100 procedure

La strada che le pagine di confronto saltano. Jenner è un'implementazione clean room del linguaggio SAS 9.4 scritta in Rust: legge direttamente i file SAS7BDAT ed esegue il sorgente .sas com'è, quindi non c'è codice generato da rivedere né un secondo linguaggio da portarsi dietro. Quello che non fa è coprire tutto il linguaggio SAS, e la copertura è pubblicata procedura per procedura, così potete controllare la vostra prima di dipenderne.

Restare dove siete

Non fare nulla è una decisione vera e spesso quella giusta. Se il codice è stabile, l'ambiente in cui gira non sparisce quest'anno e nessuno chiede un cambiamento, la migrazione che non fate ha il rendimento migliore di questa pagina. Tornateci quando un cambio di piattaforma, un audit o una difficoltà di assunzione imporranno la domanda.

Quanto costa fidarsi del codice convertito

Il modo in cui fallisce una conversione automatica non è l'errore di sintassi; quello salta fuori alla prima esecuzione. È la differenza numerica silenziosa. SAS riempie i valori carattere con spazi a destra e Python no, SAS conta le date dal 1 gennaio 1960 mentre pandas parte dal 1 gennaio 1970, e un MERGE di passo DATA non si comporta come un merge di pandas quando la chiave si ripete da entrambi i lati. Niente di tutto questo segnala qualcosa. Esce un numero quasi giusto, che è il peggior tipo di sbagliato. Per questo il prezzo vero è una lettura riga per riga da parte di chi padroneggia entrambi i linguaggi, più un periodo in cui vecchio e nuovo girano affiancati sugli stessi dati finché gli output non coincidono; e quel prezzo cresce con la quantità di codice, non con la sua ingegnosità.

Inizia la prova gratuitaLasciate che un modello di IA esegua il codice, non solo lo scriva

Domande frequenti

Sì, e gli strumenti sono migliori di prima. Convertitori web e servizi di fornitori prendono un file .sas e restituiscono Python, e un grande modello linguistico (LLM) fa lo stesso da una finestra di chat. Tutti se la cavano con la sintassi, e nessuno sa dirvi se i numeri tornano ancora. Trattate l'output come una prima stesura scritta da qualcuno che non ha mai visto i vostri dati.

No. È pubblicata da Jenner, un'implementazione indipendente e clean room del linguaggio SAS 9.4 scritta in Rust. Esegue i programmi .sas così come sono scritti, sui file SAS7BDAT che avete già. Nulla viene emesso in un altro linguaggio, quindi non c'è sorgente generato da rivedere.

Di solito un file Python per ogni programma SAS: i passi DATA resi come operazioni pandas, PROC SQL come join pandas oppure come SQL attraverso un driver di database, e le procedure statistiche mappate su statsmodels, scipy o scikit-learn dove esiste un equivalente. Dove non esiste — buona parte del linguaggio macro, l'output ODS, molti formati e informat — lo strumento lascia un commento o la sua ipotesi migliore. È in quella lacuna che se ne va il tempo di revisione.

Ce ne sono di buoni, e condividono tutti un limite che conviene conoscere prima di affidarcisi. Un prontuario fa corrispondere PROC MEANS a un describe di pandas, PROC FREQ a value_counts o a una tabella incrociata, PROC SORT a sort_values e un passo DATA a una catena di assegnazioni. Quello è lo strato della sintassi, e la sintassi non è la parte difficile. Ciò che nessuna tabella può tradurre è la semantica sottostante — gestione dei valori mancanti, elaborazione per gruppi BY, spazi finali nei confronti fra caratteri, l'origine delle date — ed è lì che il codice convertito sbaglia in silenzio.

Può, e per un programma breve è spesso la via più corta a una prima stesura. La trappola è quella di ogni convertitore, resa peggiore dalla scioltezza: un LLM scrive codice che si legge in modo convincente che sia giusto o no, e inventerà un equivalente plausibile per un'opzione di procedura che non conosce. Il rimedio non è un prompt migliore. È dare al modello un modo di eseguire entrambe le versioni e confrontare gli output, così il controllo diventa meccanico invece di dipendere da quanto suonava sicura la risposta.

Nessuno può dirvelo dall'esterno, e una pagina che vi dà un numero sta tirando a indovinare. Le due variabili che contano sono quante righe ci sono e quanto è rigida la richiesta che l'output nuovo coincida con quello vecchio. Qualche migliaio di righe senza obbligo di riproduzione è un progetto che un piccolo team porta a termine; una base validata i cui risultati passati devono essere riproducibili è un programma con un budget di test, e scrivere il codice ne è la parte piccola.

Quando l'output deve riprodurre quello che producevano i vecchi programmi e qualcuno fuori dal team lo verificherà. Quando la base è così grande che nessuno l'ha letta tutta. Quando le persone che capiscono l'analisi non sono quelle che scrivono Python. Ognuno di questi casi trasforma un lavoro di programmazione in un lavoro di validazione, ed è la validazione a far sforare questi progetti.

Eseguire i programmi SAS senza SAS. Un'implementazione indipendente del linguaggio SAS esegue il sorgente .sas che avete già, il che significa nessun codice generato da rivedere e nessun secondo linguaggio nella stanza. Jenner è uno di questi. Altair SLC, prima WPS, è un altro e lo fa da molto più tempo. Questa strada merita un preventivo ogni volta che il motivo per andarsene è la piattaforma o la licenza e non il linguaggio in sé.

Sì. I file SAS7BDAT vengono letti direttamente, quindi non serve esportare nulla in CSV prima. Conta più di quanto sembri. Una migrazione che comincia scaricando ogni dataset in testo eredita un secondo insieme di differenze — codifiche, precisione numerica, lettura delle date — sopra quelle già presenti nel codice, e dopo nessuno riesce più a dire da quale strato venga una discrepanza.

Non tutto il linguaggio SAS, ed è il limite onesto da mettere sul piatto insieme a tutto il resto. Ogni procedura implementata ha una pagina di riferimento pubblicata, quindi se una PROC specifica è supportata si verifica prima di dipenderne invece di scoprirlo dopo. I programmi che si appoggiano a opzioni di procedura poco comuni, a layout ODS o a motori di database esterni sono il primo posto dove guardare. La prova pratica è far girare i propri programmi e confrontare i log; richiede un pomeriggio e chiude la questione meglio di qualsiasi affermazione su una pagina come questa.

Altair SLC, che era WPS, esegue programmi in linguaggio SAS senza SAS e lo fa da molto più tempo di noi. Su un parco grande, dove qualcun altro ha già incontrato il vostro caso limite e se l'è fatto correggere, quella storia vale soldi veri. Mettete entrambi davanti al vostro codice e confrontate i log. La risposta di solito è ovvia nel giro di un giorno, e non siamo sempre noi.

È il finale più comune ed è ragionevole. Le analisi nuove si scrivono in Python perché lì stanno già il team e le librerie, mentre i vecchi programmi validati continuano a girare così come sono finché non c'è un motivo per toccarli. Evita la versione peggiore di questa decisione: una riscrittura in un colpo solo di codice che nessuno ha il budget di rivalidare. I due lati devono accordarsi solo al confine — sui dati che si passano — e non riga per riga.

Decidete sui vostri programmi

Il vostro codice, i vostri dati e i log affiancati. È quello il confronto che decide, ed è quello che nessuno può fare al posto vostro.

Inizia la prova gratuita