SAS a Python: lo que cuesta de verdad

La mayoría de los resultados de esta búsqueda son herramientas que producen Python a partir de código SAS, y varias lo hacen bien. Esta página empieza un paso antes: si el traslado tiene sentido para su base de código, cuánto cuesta verificar el resultado y qué hacer cuando la respuesta es que no.

La respuesta corta

Hay cuatro rutas para salir de una base de código SAS, no dos: entregarla a una herramienta automática, reescribirla a mano, ejecutar los programas SAS tal cual sobre algo que no es SAS, o dejarla en paz. Cuál es la correcta depende casi por completo de dos preguntas: cuánto código hay y si alguien tiene que reproducir los resultados anteriores. Todo lo que sigue es lo que cuesta cada ruta.

Cuándo Python es la respuesta correcta

Python es el mejor destino más veces de lo que una página como esta suele admitir. Cuatro condiciones lo dejan claro: la base de código es lo bastante pequeña para que una persona la lea en una semana, el equipo ya escribe Python a diario, el análisis se va a rehacer de todos modos y nada aguas abajo exige que las cifras nuevas coincidan exactamente con las viejas. Cuando se cumplen las cuatro, una reescritura sale más barata que cualquier capa de compatibilidad, y queda código que su equipo puede mantener sin cargar con un segundo lenguaje.

Cuatro rutas, y lo que cuesta cada una

Cada opción de aquí es la respuesta correcta para alguien. Ninguna sale sin coste, y la parte cara nunca es la sintaxis.

Un convertidor automático

Herramientas web, servicios de proveedores y grandes modelos de lenguaje toman código .sas y devuelven Python, normalmente proyectando los pasos DATA sobre pandas y los procedimientos habituales sobre statsmodels o scikit-learn. Para unos cientos de líneas de manipulación de datos sencilla es un atajo real, y da un punto de partida legible en minutos. La factura llega después: cada línea de la salida necesita que la lea alguien que conozca los dos lenguajes.

Una reescritura a mano

Alguien lee el programa SAS, deduce qué pretendía hacer y lo escribe en Python. Arranca más despacio y es la única ruta que termina con código con forma de Python y no de SAS disfrazado. Los equipos que dos años después siguen contentos con Python casi siempre llegaron así, manteniendo el programa antiguo en marcha al lado hasta que las cifras coincidieron.

Ejecutar los programas tal cual: 100 procedimientos

La ruta que las páginas de comparativa se saltan. Jenner es una implementación de sala limpia del lenguaje SAS 9.4 escrita en Rust: lee archivos SAS7BDAT directamente y ejecuta el código .sas tal como está, así que no hay código generado que revisar ni un segundo lenguaje que sostener. Lo que no hace es cubrir todo el lenguaje SAS, y la cobertura se publica procedimiento a procedimiento para que compruebe el suyo antes de depender de él.

Quedarse donde está

No hacer nada es una decisión real y a menudo la acertada. Si el código es estable, el entorno donde se ejecuta no desaparece este año y nadie pide un cambio, la migración que no hace tiene el mejor rendimiento de esta página. Vuelva a la pregunta cuando la fuerce un cambio de plataforma, una auditoría o un problema de contratación.

Lo que cuesta confiar en el código convertido

El modo de fallo de una conversión automática no es el error de sintaxis; ese aparece la primera vez que se ejecuta. Es la diferencia numérica silenciosa. SAS rellena los valores de carácter con espacios a la derecha y Python no, SAS cuenta las fechas desde el 1 de enero de 1960 y pandas desde el 1 de enero de 1970, y un MERGE de paso DATA no se comporta como un merge de pandas cuando la clave se repite en ambos lados. Nada de eso levanta un aviso. Produce un número casi correcto, que es la peor clase de error. Por eso el precio real de una conversión es una lectura línea a línea por alguien que domine los dos lenguajes, más una temporada ejecutando lo viejo y lo nuevo en paralelo sobre los mismos datos hasta que las salidas coincidan; y ese precio crece con la cantidad de código, no con su ingenio.

Preguntas frecuentes

Sí, y las herramientas son mejores que antes. Convertidores web y servicios de proveedores toman un archivo .sas y devuelven Python, y un gran modelo de lenguaje (LLM) hace lo mismo desde una ventana de chat. Todos son buenos con la sintaxis, y ninguno puede decirle si las cifras siguen cuadrando. Trate la salida como un primer borrador escrito por alguien que nunca ha visto sus datos.

No. La publica Jenner, una implementación independiente y de sala limpia del lenguaje SAS 9.4 escrita en Rust. Ejecuta los programas .sas tal como están escritos, sobre los archivos SAS7BDAT que ya tiene. No se emite nada en otro lenguaje, así que no hay código generado que nadie tenga que revisar.

Normalmente un archivo Python por programa SAS: los pasos DATA como operaciones de pandas, PROC SQL como uniones de pandas o como SQL a través de un controlador de base de datos, y los procedimientos estadísticos proyectados sobre statsmodels, scipy o scikit-learn donde existe un equivalente. Donde no existe — buena parte del lenguaje macro, la salida ODS, muchos formatos e informats — la herramienta deja un comentario o su mejor conjetura. En ese hueco se va el tiempo de revisión.

Las hay buenas, y todas comparten un límite que conviene conocer antes de apoyarse en una. Una chuleta hace corresponder PROC MEANS con un describe de pandas, PROC FREQ con value_counts o una tabla cruzada, PROC SORT con sort_values y un paso DATA con una cadena de asignaciones. Esa es la capa de sintaxis, y la sintaxis no es la parte difícil. Lo que ninguna tabla puede traducir es la semántica de debajo — tratamiento de valores ausentes, procesamiento por grupos BY, espacios finales en las comparaciones de caracteres, el origen de las fechas — y ahí es donde el código convertido se equivoca en silencio.

Sí, y para un programa corto suele ser el camino más corto hasta un primer borrador. La trampa es la de cualquier convertidor, agravada por la soltura: un LLM escribe código que se lee convincente sea correcto o no, e inventará un equivalente plausible para una opción de procedimiento que no conoce. El remedio no es un prompt mejor. Es darle al modelo una forma de ejecutar ambas versiones y comparar las salidas, para que la comprobación sea mecánica y no una cuestión de cuánta seguridad transmitía la respuesta.

Nadie puede decírselo desde fuera, y una página que le da una cifra está adivinando. Las dos variables que importan son cuántas líneas hay y cuán firme es la exigencia de que la salida nueva coincida con la vieja. Unos miles de líneas sin requisito de reproducción es un proyecto que un equipo pequeño termina; una base validada cuyos resultados previos deben ser reproducibles es un programa con presupuesto de pruebas, y escribir el código es la parte pequeña.

Cuando la salida tiene que reproducir lo que producían los programas antiguos y alguien de fuera del equipo lo va a comprobar. Cuando la base es tan grande que nadie la ha leído entera. Cuando quienes entienden el análisis no son quienes escriben Python. Cualquiera de esos casos vuelve un trabajo de programación un trabajo de validación, y la validación es lo que hace que estos proyectos se desborden.

Ejecutar los programas SAS sin SAS. Una implementación independiente del lenguaje SAS ejecuta el código .sas que ya tiene, lo que significa que no hay código generado que revisar ni un segundo lenguaje en la sala. Jenner es una de ellas. Altair SLC, antes WPS, es otra y lleva mucho más tiempo haciéndolo. Esta ruta merece presupuestarse siempre que el motivo para irse sea la plataforma o la licencia, no el lenguaje en sí.

Sí. Los archivos SAS7BDAT se leen directamente, así que no hay que exportar nada a CSV primero. Eso importa más de lo que parece. Una migración que empieza volcando cada conjunto de datos a texto hereda un segundo grupo de diferencias — codificaciones, precisión numérica, análisis de fechas — encima de las que ya trae el código, y luego nadie sabe de qué capa viene una discrepancia.

No todo el lenguaje SAS, y ese es el límite honesto que hay que poner frente a todo lo anterior. Cada procedimiento implementado tiene una página de referencia publicada, así que si un PROC concreto está soportado se comprueba antes de depender de él en vez de descubrirlo después. Los programas que se apoyan en opciones poco comunes, en diseños ODS o en motores de bases de datos externos son el primer sitio donde mirar. La prueba práctica es ejecutar sus propios programas y comparar los registros; lleva una tarde y zanja la cuestión mejor que cualquier afirmación de una página como esta.

Altair SLC, que era WPS, ejecuta programas en lenguaje SAS sin SAS y lleva haciéndolo mucho más tiempo que nosotros. En un parque grande, donde otro ya se topó con su caso raro y consiguió que lo arreglaran, esa historia vale dinero de verdad. Ponga los dos delante de su propio código y compare los registros. La respuesta suele ser obvia en un día, y no siempre somos nosotros.

Ese es el final habitual y es razonable. Los análisis nuevos se escriben en Python porque ahí están ya el equipo y las bibliotecas, mientras los programas antiguos validados siguen corriendo tal cual hasta que haya un motivo para tocarlos. Evita la peor versión de esta decisión: una reescritura de golpe de código que nadie tiene presupuesto para revalidar. Los dos lados solo tienen que coincidir en la frontera — los datos que se pasan — y no línea a línea.

Decídalo con sus propios programas

Su código, sus datos y los registros en paralelo. Esa es la comparación que lo decide, y es la que nadie puede hacer por usted.

Empezar la prueba gratuita