La biblioteca de DataFrame para Python Ibis elimina los backends de Pandas y Dask

• Se descontinúan los backends de pandas y dask, y se eliminarán en la versión 10.0
• No hay diferencia funcional entre el backend de pandas y el backend predeterminado de DuckDB, y DuckDB ofrece un rendimiento muy superior
• Los DataFrame de pandas aún pueden usarse en Ibis como formato para intercambiar datos, pero ya no se admite ejecutar consultas usando pandas
• La mayor parte de esta lógica también aplica al backend de dask, y dask sigue siendo un excelente proyecto que debe seguir usándose fuera de Ibis

¿Por qué pandas? Y la historia de Ibis

• En los inicios de Ibis solo existía el backend de Impala
• Se añadió el backend de Postgres, pero la instalación era compleja, así que los usuarios no podían probar Ibis fácilmente
• Hacía falta una forma de probar la API de Ibis sin infraestructura adicional aparte de un notebook
• En ese momento, conectar el backend de pandas, el único motor de DataFrame en memoria disponible, era la respuesta más obvia

Las dificultades del backend de Pandas

• pandas era la mejor opción en ese momento, pero no encajaba bien con el modelo de análisis de datos de Ibis
• El backend de pandas es fundamentalmente distinto de los demás backends y contiene la mayor cantidad de código especial
• pandas es esencialmente un motor de ejecución inmediata, mientras que Ibis usa un modelo de ejecución diferida
• Hacer que la interfaz de pandas funcione de forma diferida es complicado
• El backend de pandas es más lento que los demás y requiere miles de líneas de código
• NaN en pandas y NULL en Ibis son conceptos fundamentalmente distintos, pero había que tratarlos como si fueran lo mismo
  • En pandas se usó NaN como marcador de valores faltantes, pero eso causaba problemas de compatibilidad con otros backends
  • NULL representa un valor faltante, mientras que NaN significa “no es un número”; son conceptos fundamentalmente distintos
• Los nuevos tipos basados en Arrow de pandas son una gran mejora, pero aún tienen problemas

Genera confusión entre los nuevos usuarios

• La gente prefiere lo que le resulta familiar
• Al usar Ibis por primera vez, hay que elegir tanto Ibis como el backend
• Los nuevos usuarios suelen reportar que "Ibis es lento"
• En la mayoría de los casos, eso se debía a que estaban usando el backend de pandas
• Si hubieran usado DuckDB o Polars, habrían podido empezar mucho más fácilmente

Equivalencia funcional

• La razón más fuerte para eliminar el backend de pandas es la redundancia
• El backend de DuckDB puede consultar DataFrame de pandas sin problemas, admite varios tipos de UDF y puede leer y escribir múltiples formatos como parquet, CSV y JSON
• DuckDB es fácil de instalar, se ejecuta localmente, es muy rápido y se integra bien con el ecosistema de Python

Resumen de GN⁺

• Adoptar DuckDB como backend predeterminado parece una decisión muy acertada. Es fácil de instalar, se ejecuta localmente, es muy rápido y se integra bien con el ecosistema de Python. Esa también fue la razón por la que Ibis añadió originalmente pandas como backend
• Que pandas todavía pueda usarse como formato de intercambio de datos es una buena noticia para los usuarios actuales de pandas. No es necesario desechar por completo el código existente
• Sin embargo, dejar de usar pandas para ejecutar consultas parece la dirección correcta. El modelo de ejecución ansiosa de pandas no encaja con el modelo de ejecución diferida de Ibis. Por eso, el backend de pandas a menudo es mucho más lento que usar pandas directamente
• A medida que Ibis admite cada vez más backends, mantener código ajustado a backends específicos será cada vez más difícil. Eliminar el backend de pandas hará que la base de código sea más limpia y más fácil de mantener
• Si usar el backend de DuckDB puede reemplazar toda la funcionalidad de pandas, no parece haber razón para mantener el backend de pandas. De hecho, puede terminar confundiendo a los nuevos usuarios

[yangeok]

La realidad es que todavía se sigue usando mucho pandas, que es con lo que estamos más familiarizados,,

[GN⁺]

Opiniones de Hacker News

• NaN es el resultado de 0/0, lo que significa que el valor existe pero no se conoce con precisión

  • NULL significa que no se conoce el valor en una ubicación específica
  • La implementación de NaN y NULL es diferente, pero no son completamente ajenos entre sí
  • None de Python es distinto de NaN y NULL

• Hay muchos motores de cómputo mejores que pandas

  • Se sigue usando pandas por la base de código existente y las integraciones con terceros
  • Para trabajos con datos pequeños, pandas es suficientemente adecuado

• En los últimos meses, en proyectos nuevos se ha reemplazado pandas por ibis

  • La sintaxis de ibis es más flexible que la de pandas
  • El encadenamiento de operaciones hace que los fragmentos de código sean más portables
  • El backend de DuckDB es muy rápido
  • La comunidad es muy activa y amable
  • Se está recomendando ibis a los colegas

• La función de multiíndice de pandas es la más potente

  • También se puede usar en columnas
  • No hay seguridad sobre cómo manejarán esta función las herramientas nuevas

• Da curiosidad saber si han considerado Polars

  • En el grupo no les gusta pandas, así que usan Polars como estándar

• pandas puede extenderse a nuevos tipos de columnas

  • No está claro si Polars admite eso

• El valor de Ibis no está en que permita usar DuckDB

  • Aunque aparezcan herramientas nuevas, la sintaxis sigue funcionando

• No se ha oído hablar mucho de Ibis

  • Si se deja pandas, es menos probable que se pruebe Ibis
  • Los frameworks nuevos se están alejando de pandas/numpy, pero se planea esperar hasta que se resuelvan la compatibilidad y los casos límite
  • No importa esperar unos milisegundos más

• La API de la biblioteca pandas no siempre es intuitiva

  • Existe el problema de NaN/None, pero es una molestia menor

• La razón para usar pandas es su ecosistema integrado

  • pandas es conveniente al leer datos desde archivos json, archivos csv, python dict, etc., y visualizarlos con plotly
  • Si Ibis fuera compatible con los dataframes de pandas, no importaría demasiado el backend