Microsoft planea incorporar Python en Excel

 (theverge.com)
1 puntos por GN⁺ 2023-08-23 | 1 comentarios | Compartir por WhatsApp
  • Microsoft comenzó a ofrecer en vista previa pública una integración que permite hacer análisis y visualización de datos basados en Python dentro de Excel
  • Sin instalaciones adicionales, se puede acceder a Python desde la cinta de Excel y refinar los resultados junto con las fórmulas, gráficos y PivotTable existentes
  • La nueva función PY expone datos de Python en la cuadrícula de la hoja de cálculo, y gracias a la colaboración con Anaconda es posible usar pandas, statsmodels, Matplotlib y más dentro de Excel
  • Los cálculos no se ejecutan localmente, sino en Microsoft Cloud, y luego regresan a la hoja de cálculo; también se pueden crear visualizaciones basadas en Matplotlib y Seaborn
  • La vista previa pública comienza en Windows dentro del Beta Channel de Microsoft 365 Insiders y, una vez finalizada la vista previa, algunas funciones quedarán limitadas sin una licencia de pago

Análisis con Python dentro de Excel

  • Microsoft agregó a Excel una integración con Python que permite manipular y analizar datos dentro de una hoja de cálculo
  • Los usuarios pueden acceder directamente a Python desde la cinta de Excel, lo que les permite continuar con tareas de análisis avanzadas sin salir del entorno de Excel que ya conocen
  • Los gráficos y resultados de bibliotecas creados con Python pueden combinarse con fórmulas, gráficos y PivotTable de Excel para refinarlos aún más

Integración incorporada sin instalación adicional

  • La integración con Python se ofrece como parte de los conectores integrados de Excel y de Power Query
  • Se puede acceder a ella sin instalar software adicional ni configurar complementos aparte
  • La nueva función PY expone datos de Python dentro de la cuadrícula de la hoja de cálculo de Excel

Bibliotecas de Anaconda y visualización

  • Microsoft colaboró con Anaconda, el repositorio empresarial de Python, para permitir el uso de bibliotecas clave de Python en Excel
  • Entre las bibliotecas disponibles se incluyen:
    • pandas
    • statsmodels
    • Matplotlib
  • Los usuarios de Excel pueden crear fórmulas, PivotTable y gráficos a partir de datos de Python
  • Con bibliotecas de gráficos como Matplotlib y Seaborn, pueden generar las siguientes visualizaciones:
    • heatmap
    • violin plot
    • swarm plot

Los cálculos se procesan en Microsoft Cloud

  • El código Python se escribe y se usa dentro de la hoja de cálculo de Excel, pero el procesamiento de los cálculos no se realiza en el Excel local, sino en Microsoft Cloud
  • Los resultados de la ejecución se devuelven luego a la hoja de cálculo de Excel

Disponibilidad y condiciones de licencia

  • La vista previa pública de Python in Excel está disponible en el Beta Channel de Microsoft 365 Insiders
  • La disponibilidad inicial está limitada a Windows
  • Microsoft planea ampliarla más adelante a otras plataformas
  • Durante el periodo de vista previa, está incluida en la suscripción de Microsoft 365
  • Una vez finalizada la vista previa, algunas funciones quedarán limitadas si no se cuenta con una licencia de pago

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-08-23
Opiniones de Hacker News

  • Como alguien que antes trabajó como desarrollador de Excel e intentó, sin éxito, meter Python en Excel, la noticia de hoy es una grata sorpresa.
    Hace unos 7 años tuve la oportunidad de dejar el equipo de Excel, pero en ese momento el jefe de mi jefe se enteró de que yo quería incorporar Python en Excel y me dijo que, si me quedaba, me encargaría de eso. Lo que pensé que sería un trabajo de 6 meses se convirtió en un proyecto de casi 3 años y, mientras lo de Python se fue diluyendo, al final se lanzó en la dirección de incorporar funciones personalizadas de JavaScript en Excel.
    Python también se ejecutaba “en la nube” sobre AzureML v1, pero hubo idas y vueltas sobre si debía ejecutarse localmente. Hubo reorganizaciones, relanzamientos, recontrataciones y salidas de PM en el equipo socio de AzureML, y cuando otro equipo socio se dio cuenta de que podía usar nuestro código para ejecutar JavaScript en un proceso externo, terminamos dedicando mucho más tiempo a lanzar esa funcionalidad que a Python.
    El trabajo central fue cambiar el motor de cálculo de Excel para que las funciones pudieran hacer cálculos asíncronos, permitiendo que el usuario siguiera trabajando en otras partes de la hoja de cálculo mientras un endpoint remoto calculaba, ya fuera JavaScript, Python o cualquier otra cosa. Antes, durante el cálculo, la hoja quedaba bloqueada, lo cual no era bueno para cálculos largos y sin un final claro. Me pregunto si algo de lo que construimos entró en esta función.
    “Recalcular o morir”

    • Gracias a las funciones asíncronas de JavaScript pudimos lanzar funciones personalizadas estables con xlwings y Python.
      El problema de Office.js es que para el usuario promedio de Excel es demasiado difícil empezar por el montón de dependencias de npm, e incluso los desarrolladores profesionales sufren bastante. Me alegra que hayamos hecho que los usuarios no tengan que usar Node.js: https://docs.xlwings.org/en/latest/pro/server/officejs_custo...
    • Hace unos años ya había creado un “Python dentro de Excel” que funcionaba, y también ejecutaba SQL y Matlab/R de forma remota.
      Es un proyecto abandonado ahora: https://alphawolfxl.com/
      Se lo pedí a varias personas para pruebas beta y me dijeron que “la empresa no pagaría por eso”, así que me quedé con la impresión de que había perdido el tiempo y lo dejé. Ver esto ahora me deja sentimientos encontrados.
    • Me pregunto por qué Microsoft no creó buenos ejemplos reales de la nueva tecnología. Los pocos ejemplos que ofrecieron son solo para programadores.
      En general faltan códigos funcionales reales para ver cómo funciona JavaScript en Excel, y ahora se siente casi al nivel de “cómo dibujar un búho”.
    • Estamos usando funciones personalizadas de JavaScript para llamar a nuestra API interna de análisis, y resultó bastante agradable trabajar con eso.

  • Me gustaría que también admitiera ejecución local de Python, y no solo el enfoque de usar Microsoft Cloud, pero aun así esta sola función podría modernizar mucho Excel.
    Incluso podría eliminar la necesidad de sitios web que intentan mostrar este tipo de datos. En un trabajo anterior hice un sitio web interno de análisis que solo usaban unas pocas personas, y si esta función hubiera existido entonces, creo que habría sido suficiente para reemplazarlo.

    • Cada vez que digo esto recibo resistencia. Los usuarios simplemente quieren analizar datos libremente en Excel, pero el área de TI donde estoy intenta hacerles una web app que haga eso por ellos. Al final los usuarios no quedan satisfechos, porque lo que querían desde el principio era Excel.
      Sigo explicando que basta con crear un data mart en SQL Server y llenarlo con los datos necesarios para el análisis mediante herramientas ETL. No hace falta darles acceso a los datos de origen. Pero aun así todos me miran raro y, en cambio, quieren hacer un proyecto de implementación de Tableau de varios millones de dólares. Es absurdo, porque los usuarios no quieren eso.
    • Trabajo en el equipo de Excel. Si me mandas a bgruenbaum@microsoft.com un resumen de por qué eso es importante, se lo pasaré al PM.
      O también puedes enviarlo mediante la UI de comentarios de Excel web/escritorio. Los PM leen todo ese feedback.
    • Hay varias razones importantes para ejecutarlo en contenedores aislados por hipervisor de Azure sin acceso a Internet.
      Podemos garantizar una experiencia consistente para todos los usuarios. Da terror pensar que, con el tiempo y la divergencia de versiones, cada quien tendría que mantener su propia distribución local de Python y garantizar que funcione con Excel.
      Podemos hacer que, cuando compartas un libro de Excel con otro usuario, los cálculos simplemente funcionen. Si dependieran de instalaciones locales de Python todas distintas, eso no pasaría y el usuario se frustraría mucho.
      La seguridad también es enorme. Basta imaginar abrir un archivo de Excel que pueda ejecutar código Python con los permisos del usuario local.
      También estoy totalmente de acuerdo con el segundo punto. Crear en Python apps internas que se integren con la infraestructura de TI existente es, siendo generosos, frustrante. Excel ya forma parte de la infraestructura de TI en casi todos lados, y es un lienzo reactivo y programable.
      Aclaración: trabajo en el equipo de diseño de esta función.
    • El hecho de que se ejecute en Microsoft Cloud podría hacerlo más útil que las macros en nuestra empresa.
      Aquí las macros se ven como una vía para ejecutar malware en las máquinas cliente, y se considera que su utilidad no es tan grande como para asumir ese riesgo.
    • Limitarlo a la nube tiene cierto sentido. Si convierten Python en una parte central del formato de archivo de Excel, se reduciría la portabilidad y podrían aparecer todo tipo de dolores de cabeza de compatibilidad en el futuro.

  • Aquí se ve claramente una señal de alerta. La fuerza esencial de Excel viene de que un libro de trabajo puede existir de forma independiente, pero ahora el proceso queda atado para siempre a la nube.
    Cuando dentro de 3 años haya que abrir el libro de trabajo de un colega fallecido, dependerá de si el proveedor sigue dando soporte a esta integración.
    Es terrible cuando el primer paso de cualquier tarea pasa a ser “averiguar cómo hacer que el software vuelva a funcionar”. Me ha pasado varias veces durante las últimas décadas por todo tipo de complementos de Excel, Outlook y Word, y esos complementos ni siquiera hacían el procesamiento de forma remota.

    • ¿Ahora aquello de “no tendrás nada, pero serás feliz” llegó incluso a las hojas de cálculo? Ya ni siquiera se puede ser dueño de lo que uno crea trabajando asalariado frente a un escritorio.
    • Sinceramente, esto parece más fácil de administrar. Como usa la distribución de Anaconda, si se vincula cada libro de trabajo a una distribución específica y se permite actualizar/revertir, resulta mucho más sencillo que administrar instalaciones locales.
    • No solo queda atado a la nube, sino también a una suscripción. Si cancelas la suscripción, si no tienes esa suscripción que en la presentación dijeron que podría ser un módulo de pago, o si usas un Excel proporcionado por un proveedor y no tienes suscripción, ya tendrás problemas para usar esa hoja de Excel.
    • En los últimos 7 años, más o menos, no he usado hojas de cálculo que no estén en la nube. Pero no usaría Excel para trabajos importantes y de larga vida. Lo uso sobre todo para lluvia de ideas o para capturas de pantalla que van en presentaciones.
    • Uses la nube o no, este problema ya existe. Las hojas de Excel ya pueden tener enlaces externos a la web o a otros archivos, y si ese recurso web o archivo no existe, se acabó. Los archivos antiguos quizá solo puedan abrirse con software que ya no corre en máquinas modernas.
      Por eso es importante restaurar de vez en cuando las copias de seguridad en la práctica o, en casos así, verificar los archivos importantes.

  • Me entusiasmé con “Python en Excel”, pero se me pasó al ver la frase “se ejecuta en la nube”. No parece haber otra razón que mantenerte atado a un servicio en la nube. Se siente demasiado parecido a que quieran protegerme de la tinta de impresora insegura.
    Por lo general me gustan los productos de MS Office y tiendo a darles el beneficio de la duda. Si hay una buena razón plausible para exigir que Python se ejecute en la nube, aparte del lock-in, me gustaría conocerla.

    • Es una señal de alerta. M$ está empujando a la gente hacia su nube. La forma en que OneDrive se apropia del sistema de archivos local es un buen ejemplo que muchos ya han sufrido.
      Creo que el momento de alejarse de M$ pasó hace unos 5 años. Desde Windows hasta Office, todos sus productos ya tienen funciones anticonsumidor.
    • No pedirle al cliente que administre una instalación local de Python puede ser una razón.
      Aunque, claro, entiendo que los usuarios avanzados de Excel+Python probablemente estén acostumbrados a traer y mantener su propio runtime de Python.
    • Probablemente sea porque la mayoría de los usuarios de Excel nunca ha instalado ni ejecutado Python. Incluso para alguien que conoce Python puede ser bastante molesto.
      También hay gente que usa Excel en dispositivos iOS y Android. Con este enfoque, ellos también pueden usar y leer Python dentro de una hoja de cálculo.
    • También está Grist. No es un clon de Excel, pero es una hoja de cálculo/base de datos híbrida, así que puede hacer algunas cosas parecidas, y lo más importante es que permite usar Python en las fórmulas y tiene opción de self-hosting si quieres correrlo localmente.

  • En 2005, con unos amigos creamos una empresa llamada Resolver Systems e hicimos Resolver One, una hoja de cálculo con Python.
    Lamentablemente no despegó en el mercado, así que cambiamos de rumbo y creamos PythonAnywhere, un entorno online de codificación y hosting, que sí funcionó bastante bien y el año pasado fue adquirido por Anaconda. Y ahora el círculo se cerró.
    Para aclarar: dentro de Anaconda, el equipo que desarrolla esta función es completamente distinto del equipo de PythonAnywhere. Si fueran las mismas personas, habría sido una historia perfecta al estilo Hollywood.

    • Era un buen producto. Recuerdo el pitch y también nos vimos varias veces en el encuentro de Python financiero de Londres. También recuerdo “Enthought Python Distribution”.
      Pero el problema era que Resolver estaba basado en IronPython, así que había bastantes librerías que no funcionaban bien.
    • Hice mi primera app en PythonAnywhere. Algunas cosas llevan casi 10 años corriendo ahí.
      Me encantaba poder hacer pequeñas correcciones directamente desde la webapp de PythonAnywhere, y cuando empecé a usar GCP/AWS extrañé mucho esa función.
    • PythonAnywhere es excelente. Como a otros, también fue el lugar donde di mis primeros pasos en programación web.
    • Apenas escuché esta noticia, enseguida pensé en Resolver Systems.

  • Al ver la frase “los cálculos de Python se ejecutan en Microsoft Cloud”, un colega bromeó: “Parece que ni Microsoft puede administrar una instalación local de Python en Windows…”.
    Pero es divertido imaginar que Microsoft por fin resuelve de verdad el problema de configurar entornos locales de Python, y que Excel se convierte en el administrador estándar de paquetes de Python para todo el sistema operativo.
    $ excelpip install fastapi==9.11.23
    Buscando fastapi version 11.09.2023…

    • Desde que toqué apt de Debian hace 20 años, he estado esperando que Microsoft resolviera la gestión de paquetes en Windows. No lo digo con sarcasmo: viendo la complejidad de los productos de Microsoft y su obsesión por la compatibilidad hacia atrás, parecía justamente el actor capaz de hacer avanzar la gestión de software.
      Pensé que profundizaría en el espacio del problema y reinventaría un administrador de paquetes que superara lo que salió del mundo open source.
      En cambio, ahora tenemos Windows Update, Windows Features, Microsoft Store, Software Center y winget. winget es el administrador de paquetes para Windows hecho por Microsoft, esa herramienta que tienes que instalar desde otro administrador de paquetes para Windows hecho por Microsoft.
    • Se me ocurre este problema: ¿Microsoft debería fijar un conjunto de paquetes LTSC? ¿Cómo colaborará con el resto del mundo una $GOV_AGENCY que usa una versión de Excel una generación atrasada?

  • LibreOffice debería haber leído el ambiente hace mucho tiempo. En principio es posible hacer scripting con Python, pero es demasiado engorroso y desordenado, y no parece haber una hoja de ruta de mejoras
    La misma advertencia aplica al escritorio Linux y a sus apps en general. Cada vez más plataformas propietarias, basadas en la nube, a menudo mediante API de Python, incorporarán extensiones de funciones avanzadas de “IA” en apps existentes
    Es una lástima que varias corrientes del mundo open source estén tan siloizadas. Se está desperdiciando un potencial mayor que la suma de sus partes

    • En muchos casos, lo que mantiene a la gente atada a Excel y otros productos propietarios no son las funciones avanzadas, sino cosas que parecen menores
      Lo que más me molesta en las hojas de cálculo de LibreOffice y Apple Numbers es cómo manejan copiar/pegar selecciones no contiguas
      Por ejemplo, si en datos de 5 filas y 3 columnas seleccionas y copias las filas 1 2 3, 7 8 9, a b c, y luego las pegas debajo de d e f, Excel pega solo las filas seleccionadas una tras otra. LibreOffice y Numbers preservan incluso las filas vacías intermedias
      No encontré ninguna configuración para cambiar este comportamiento. Excel también podría ser molesto para quienes quieran preservar los espacios, pero yo casi nunca he querido hacerlo, así que LibreOffice y Numbers me resultan incómodos
    • LibreOffice incluye scripting con Python casi desde el principio
      La razón por la que a la gente no le importa mucho es que el caso de uso más popular de las suites de oficina es interoperar con los formatos de archivo de Microsoft
    • Vale la pena revisar ScriptForge: https://help.libreoffice.org/latest/en-US/text/sbasic/shared...
      Para ejecutar scripts dentro de LibreOffice, se recomienda APSO script organiser: https://extensions.libreoffice.org/en/extensions/show/apso-a...
    • Más bien lo veo al revés. Python hace que el scripting sea tan fácil que Excel estaría clavando un clavo en su propio ataúd
      A medida que la base de usuarios mayores que nunca ha usado un lenguaje de programación envejece y se jubila, quienes aprendan a combinar Python con Excel terminarán prefiriendo Python. Porque es más flexible y extensible
      Fuera del uso básico como tabla de cálculo, no hay razón para usar Excel. Si alguien me pide una hoja de cálculo, automatizo su generación con Python para no tener que volver a tocarla manualmente
    • LibreOffice tiene muchos otros problemas que resolver primero. Es demasiado lento

  • Decepcionante
    “Python en Excel está disponible actualmente para usuarios que ejecutan el canal beta en Windows. Esta característica se implementará primero en Excel para Windows a partir de la compilación 16.0.16818.2000, y luego estará disponible en otras plataformas.” [1]
    “Python en Excel está disponible en Excel para Windows. Esta característica no está disponible en Excel para Mac, Excel para la Web, Excel para iPad, Excel para iPhone ni Excel para Android. En plataformas no compatibles, se pueden ver libros que contienen Python, pero si se recalculan celdas de Python aparecerá un error.” [2]
    [1] https://techcommunity.microsoft.com/t5/excel-blog/announcing...
    [2] https://support.microsoft.com/en-us/office/introduction-to-p...

  • “Los cálculos de Python se ejecutan en Microsoft Cloud”, no gracias

    • Esa parte también me llamó la atención. Me pregunto por qué eligieron este modelo
    • Quiero desesperadamente una excelente integración de Python en una suite de hojas de cálculo, pero esto ni siquiera pienso probarlo

  • Un momento. LibreOffice tenía Python desde hace años y a nadie le importó; en cambio, se quejaban de que para el “trabajo real” hacía falta VBA 100% compatible. ¿Dónde está esa gente ahora?

    • Aquí. El problema no es solo VBA 100% compatible, sino que hay que aprender una API completamente nueva para crear hojas de cálculo basadas en VBA que no se ejecutarán en Excel
      Si el VBA de LibreOffice hubiera sido compatible con el VBA de Office, no habría razón para seguir manteniendo un sistema Windows viejo guardado en algún lado
      Hacemos esto para ganar dinero, y nadie quiere comprar una hoja de cálculo de Excel que no se ejecute en Excel
    • No es que me moleste que Excel pueda hacer más cosas, sino que LibreOffice todavía puede resultar incómodo porque le faltan funciones a las que uno está acostumbrado o que se ve obligado a usar
    • Si alguno de mis clientes usara LibreOffice, lo usaría con gusto. Pero nadie lo usa
      Trabajo con LibreOffice Calc en Linux, y como Excel no tiene soporte para Linux en absoluto, me gustaría que hubiera suficiente compatibilidad como para poder enviárselo a los clientes sin problemas, pero todavía no estamos ni cerca
    • Si la función es mala, la gente no la usa
      Si la gente no sabe que existe, no la usa
      Si está acostumbrada a otra cosa, exige eso
    • El problema de LibreOffice era que el soporte de Python existía solo en la documentación