Microsoft will Python in Excel einführen

 (theverge.com)
1 Punkte von GN⁺ 2023-08-23 | 1 Kommentare | Auf WhatsApp teilen
  • Microsoft hat begonnen, eine integrierte Funktion als Public Preview bereitzustellen, mit der Python-basierte Datenanalyse und Visualisierung direkt in Excel möglich sind
  • Ohne separate Installation lässt sich Python über das Excel-Menüband aufrufen, und Ergebnisse können zusammen mit bestehenden Formeln, Diagrammen und PivotTables weiter verfeinert werden
  • Die neue PY-Funktion macht Python-Daten im Tabellenraster sichtbar; durch die Zusammenarbeit mit Anaconda lassen sich pandas, statsmodels, Matplotlib und weitere Bibliotheken in Excel nutzen
  • Berechnungen laufen nicht lokal, sondern in der Microsoft Cloud und werden anschließend ins Arbeitsblatt zurückgegeben; auch Visualisierungen auf Basis von Matplotlib und Seaborn können erstellt werden
  • Die Public Preview startet zunächst unter Windows im Beta Channel von Microsoft 365 Insiders; nach Ende der Preview werden einige Funktionen ohne kostenpflichtige Lizenz eingeschränkt

Python-Analyse direkt in Excel

  • Microsoft ergänzt Excel um eine Python-Integration, mit der sich Daten innerhalb der Tabellenkalkulation bearbeiten und analysieren lassen
  • Nutzer können direkt über das Excel-Menüband auf Python zugreifen und anspruchsvolle Analysen fortsetzen, ohne die vertraute Excel-Umgebung zu verlassen
  • Mit Python erstellte Plots und Bibliotheksergebnisse lassen sich mit Excel-Formeln, Diagrammen und PivotTables kombinieren und weiter bearbeiten

Integriert ohne separate Installation

  • Die Python-Integration wird als Teil der integrierten Konnektoren von Excel und von Power Query bereitgestellt
  • Der Zugriff ist ohne Installation zusätzlicher Software oder Einrichtung separater Add-ins möglich
  • Die neue PY-Funktion macht Python-Daten im Excel-Tabellenraster sichtbar

Anaconda-Bibliotheken und Visualisierung

  • Microsoft arbeitet mit Anaconda, dem Enterprise-Python-Repository, zusammen, um wichtige Python-Bibliotheken in Excel nutzbar zu machen
  • Zu den verfügbaren Bibliotheken gehören:
    • pandas
    • statsmodels
    • Matplotlib
  • Excel-Nutzer können auf Basis von Python-Daten Formeln, PivotTables und Diagramme erstellen
  • Mit Diagrammbibliotheken wie Matplotlib und Seaborn lassen sich folgende Visualisierungen erzeugen:
    • Heatmap
    • Violin Plot
    • Swarm Plot

Berechnungen laufen in der Microsoft Cloud

  • Python-Code wird zwar innerhalb einer Excel-Tabelle geschrieben und verwendet, die Berechnung erfolgt jedoch nicht lokal in Excel, sondern in der Microsoft Cloud
  • Die Ausführungsergebnisse werden anschließend wieder an das Excel-Arbeitsblatt zurückgegeben

Verfügbarkeit und Lizenzbedingungen

  • Die Public Preview von Python in Excel ist im Beta Channel von Microsoft 365 Insiders verfügbar
  • Der anfängliche Rollout ist auf Windows beschränkt
  • Microsoft plant, die Funktion später auch auf weitere Plattformen auszuweiten
  • Während der Preview-Phase ist sie im Microsoft-365-Abonnement enthalten
  • Nach Ende der Preview werden einige Funktionen ohne kostenpflichtige Lizenz eingeschränkt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-08-23
Meinungen auf Hacker News

  • Als jemand, der früher als Excel-Entwickler gearbeitet und versucht hat, Python in Excel zu integrieren – und damit gescheitert ist –, ist diese Nachricht heute eine erfreuliche Überraschung.
    Vor etwa sieben Jahren hatte ich die Gelegenheit, das Excel-Team zu verlassen. Damals erfuhr der Vorgesetzte meines Chefs, dass ich Python in Excel bringen wollte, und sagte, wenn ich bleibe, würde er mir diese Aufgabe übertragen. Was ich für eine Sache von sechs Monaten hielt, wurde zu einem etwa dreijährigen Projekt; der Python-Teil trat in den Hintergrund, und am Ende wurde es in Form von benutzerdefinierten JavaScript-Funktionen in Excel ausgeliefert.
    Python lief ebenfalls „in der Cloud“ auf Basis von AzureML v1, aber es gab Diskussionen darüber, ob es auch lokal ausgeführt werden sollte. Im AzureML-Partnerteam gab es Umstrukturierungen, Neustarts, Neueinstellungen und PM-Abgänge, und als ein anderes Partnerteam bemerkte, dass es unseren Code nutzen konnte, um JavaScript in einem externen Prozess auszuführen, verbrachten wir schließlich mehr Zeit damit, diese Funktion auszuliefern, als mit Python.
    Die Kernarbeit bestand darin, die Excel-Berechnungs-Engine so zu ändern, dass Funktionen asynchron berechnen können. Dadurch konnten Nutzer weiter an anderen Teilen der Tabelle arbeiten, während ein Remote-Endpunkt – ob JavaScript, Python oder etwas anderes – rechnete. Früher war die Tabelle während der Berechnung gesperrt, was für lange und in ihrer Dauer unklare Berechnungen schlecht war. Ich frage mich, ob Teile dessen, was wir gebaut haben, in diese Funktion eingeflossen sind.
    „Recalc or die“

    • Dank asynchroner JavaScript-Funktionen konnten wir mit xlwings und Python stabile benutzerdefinierte Funktionen veröffentlichen.
      Das Problem mit Office.js ist, dass der Einstieg für durchschnittliche Excel-Nutzer wegen des ganzen npm-Abhängigkeitsballasts viel zu schwer ist, und selbst professionelle Entwickler haben ordentlich damit zu kämpfen. Ich bin zufrieden damit, dass wir dafür gesorgt haben, dass Nutzer kein Node.js verwenden müssen: https://docs.xlwings.org/en/latest/pro/server/officejs_custo...
    • Vor ein paar Jahren hatte ich bereits ein funktionierendes „Python in Excel“ gebaut; remote liefen auch SQL und Matlab/R.
      Inzwischen ist das ein aufgegebenes Projekt: https://alphawolfxl.com/
      Ein paar Leute, die ich um Beta-Tests bat, sagten, „die Firma wird dafür nicht zahlen“, woraufhin ich den Eindruck hatte, meine Zeit verschwendet zu haben, und es einstellte. Wenn ich das jetzt sehe, habe ich gemischte Gefühle.
    • Ich frage mich, warum Microsoft keine vernünftigen Beispiele für die neue Technologie erstellt hat. Die wenigen bereitgestellten Beispiele richten sich nur an Programmierer.
      Insgesamt fehlt es an tatsächlich lauffähigem Code, mit dem man sich ansehen kann, wie JavaScript in Excel funktioniert; derzeit fühlt es sich fast wie „Wie man eine Eule zeichnet“ an.
    • Wir verwenden benutzerdefinierte JavaScript-Funktionen, um unsere interne Analyse-API aufzurufen, und die Arbeit damit war ziemlich angenehm.

  • Ich würde mir wünschen, dass nicht nur die Microsoft Cloud genutzt wird, sondern auch lokale Python-Ausführung unterstützt wird. Trotzdem könnte allein diese Funktion Excel erheblich modernisieren.
    Sie könnte auch die Nachfrage nach Websites beseitigen, die solche Daten darstellen sollen. In einem früheren Job habe ich einmal eine Analyse-Website gebaut, die nur ein paar interne Leute nutzten; wenn es damals diese Funktion gegeben hätte, hätte man sie meiner Meinung nach gut dadurch ersetzen können.

    • Wenn ich das anspreche, bekomme ich immer Gegenwind. Die Nutzer wollen ihre Daten einfach frei in Excel analysieren, während die IT, zu der ich gehöre, eine Web-App bauen will, die das für sie übernimmt. Am Ende sind die Nutzer nicht zufrieden, weil sie ursprünglich Excel wollten.
      Ich erkläre immer wieder, dass man mit SQL Server einen Data Mart bauen und ihn mit einem ETL-Tool einfach mit den für die Analyse nötigen Daten befüllen kann. Auf die Rohdaten muss man ihnen keinen Zugriff geben. Trotzdem schauen mich alle seltsam an und wollen stattdessen ein millionenschweres Tableau-Einführungsprojekt machen. Die Nutzer wollen das nicht – wirklich absurd.
    • Ich arbeite im Excel-Team. Wenn du kurz zusammenfassen kannst, warum das wichtig ist, und es an bgruenbaum@microsoft.com schickst, leite ich es an die PMs weiter.
      Alternativ kannst du es auch über die Feedback-UI von Excel Web/Desktop senden. Die PMs lesen dieses Feedback vollständig.
    • Es gibt einige wichtige Gründe dafür, das Ganze in hypervisorisolierten Containern in Azure ohne Internetzugang auszuführen.
      So lässt sich für alle Nutzer eine konsistente Erfahrung gewährleisten. Wenn man sich vorstellt, dass jeder über die Zeit auseinanderlaufende lokale Python-Distributionen pflegen und deren Zusammenspiel mit Excel sicherstellen müsste, ist das grauenhaft.
      Wenn eine Excel-Arbeitsmappe mit anderen Nutzern geteilt wird, sollen die Berechnungen einfach funktionieren. Wenn sie von jeweils unterschiedlichen lokalen Python-Installationen abhängen, funktioniert das nicht, und die Nutzer wären sehr frustriert.
      Sicherheit ist ebenfalls ein großes Thema. Man muss sich nur vorstellen, eine Excel-Datei zu öffnen, die Python-Code mit lokalen Nutzerrechten ausführen kann.
      Dem zweiten Punkt stimme ich ebenfalls voll zu. Interne Apps in Python zu bauen, die sich in die bestehende IT-Infrastruktur integrieren, ist bestenfalls mühsam. Excel ist fast überall bereits Teil der IT-Infrastruktur und eine programmierbare, reaktive Arbeitsfläche.
      Offenlegung: Ich arbeite im Design-Team dieser Funktion.
    • Dass es in der Microsoft Cloud ausgeführt wird, könnte es in unserem Unternehmen sogar nützlicher machen als Makros.
      Hier gelten Makros als Weg, Malware auf Client-Maschinen auszuführen, und ihr Nutzen wird nicht als groß genug angesehen, um dieses Risiko einzugehen.
    • Die Beschränkung auf die Cloud ergibt in gewissem Maß Sinn. Wenn Python zu einem Kernbestandteil des Excel-Dateiformats wird, leidet die Portabilität, und künftig könnten allerlei Kompatibilitätsprobleme entstehen.

  • Hier gibt es eindeutig Warnsignale. Die eigentliche Stärke von Excel besteht darin, dass Arbeitsmappen eigenständig existieren können; jetzt wird der Prozess für immer an die Cloud gebunden
    Wenn man in drei Jahren die Arbeitsmappe eines verstorbenen Kollegen öffnen muss, hängt alles davon ab, ob der Anbieter diese Integrationsfunktion weiterhin unterstützt
    Es ist furchtbar, wenn bei irgendeiner Aufgabe der erste Schritt lautet: „Herausfinden, wie man die Software wieder zum Laufen bringt“. Das habe ich in den vergangenen Jahrzehnten wegen diverser Add-ins für Excel, Outlook und Word mehrfach erlebt, und diese Add-ins haben die Verarbeitung nicht einmal remote erledigt

    • „Ihr werdet nichts besitzen und glücklich sein“ ist jetzt also auch bei Tabellenkalkulationen angekommen. Nicht einmal das, was man als Lohnarbeiter am Schreibtisch erstellt, darf man besitzen
    • Ehrlich gesagt wirkt diese Variante leichter zu verwalten. Da die Anaconda-Distribution genutzt wird, kann man jede Arbeitsmappe an eine bestimmte Distribution binden und Updates/Rollbacks ermöglichen; das ist viel einfacher, als lokale Installationen zu verwalten
    • Es ist nicht nur an die Cloud gebunden, sondern auch an ein Abo. Wenn man das Abo kündigt, das in der Ankündigung womöglich als kostenpflichtiges Modul erwähnte Abo nicht hat oder Excel vom Lieferanten bekommen hat und daher kein Abo besitzt, hat man bereits ein Problem beim Nutzen dieser Excel-Tabelle
    • In den letzten etwa sieben Jahren habe ich keine Tabellenkalkulation genutzt, die nicht in der Cloud war. Für wichtige und langlebige Arbeit würde ich Excel allerdings nicht verwenden. Hauptsächlich nutze ich es für Brainstorming oder um Screenshots in Präsentationsunterlagen einzufügen
    • Ob mit Cloud oder ohne: Dieses Problem existiert bereits. Excel-Arbeitsblätter können schon heute externe Links auf das Web oder andere Dateien enthalten, und wenn diese Webressourcen oder Dateien fehlen, ist Schluss. Alte Dateien lassen sich womöglich nur noch mit Software öffnen, die auf modernen Rechnern nicht mehr läuft
      Deshalb ist es wichtig, Backups gelegentlich tatsächlich wiederherzustellen oder in solchen Fällen wichtige Dateien zu validieren

  • Ich war erst begeistert von „Python in Excel“, bis ich die Formulierung „Ausführung in der Cloud“ sah. Dafür scheint es keinen anderen Grund zu geben, als einen an einen Cloud-Dienst zu binden. Es fühlt sich viel zu sehr danach an, als wolle man mich vor unsicherer Druckertinte schützen
    Normalerweise mag ich MS-Office-Produkte und bin geneigt, ihnen wohlwollend zu begegnen. Wenn es einen plausiblen guten Grund außer Lock-in gibt, Python in der Cloud ausführen zu müssen, würde ich ihn gern hören

    • Warnsignal. M$ drängt die Leute in die eigene Cloud. Die Art, wie OneDrive das lokale Dateisystem kapert, ist ein gutes Beispiel, das viele schon erlebt haben
      Meiner Ansicht nach hätte man M$ schon vor etwa fünf Jahren verlassen sollen. Von Windows bis Office stecken bereits in allen Produkten verbraucherfeindliche Funktionen
    • Kunden nicht zum Verwalten einer lokalen Python-Installation zu zwingen, kann ein Grund sein
      Natürlich verstehe ich auch, dass fortgeschrittene Excel+Python-Nutzer wahrscheinlich daran gewöhnt sind, ihre eigene Python-Runtime mitzubringen und zu pflegen
    • Wahrscheinlich deshalb, weil die meisten Excel-Nutzer noch nie Python installiert und ausgeführt haben. Selbst für Leute, die Python kennen, ist das ziemlich lästig
      Es gibt auch Leute, die Excel auf iOS- und Android-Geräten nutzen. Auf diese Weise können auch sie Python in der Tabellenkalkulation verwenden und lesen
    • Es gibt auch Grist. Es ist kein Excel-Klon, aber als Tabellenkalkulations-/Hybrid-Datenbank kann es teilweise ähnliche Dinge leisten, und das Wichtigste: Man kann Python in Formeln verwenden, und wenn man es lokal betreiben möchte, gibt es auch eine Self-Hosting-Option

  • 2005 habe ich mit Freunden eine Firma namens Resolver Systems gegründet und Resolver One entwickelt, eine Tabellenkalkulation mit Python-Unterstützung
    Leider setzte sie sich am Markt nicht durch, und wir schwenkten um auf PythonAnywhere, eine Online-Coding- und Hosting-Umgebung. Das lief ziemlich gut und wurde letztes Jahr von Anaconda übernommen. Und nun schließt sich der Kreis
    Zur Klarstellung: Das Team innerhalb von Anaconda, das diese Funktion entwickelt, ist komplett getrennt vom PythonAnywhere-Team. Wären es dieselben Leute gewesen, wäre das eine perfekte Hollywood-Geschichte

    • Es war ein gutes Produkt. Ich erinnere mich an den Pitch und bin ihnen auch ein paar Mal beim Londoner Python-Finanztreffen begegnet. An die „Enthought Python Distribution“ erinnere ich mich ebenfalls
      Das Problem war allerdings, dass Resolver auf IronPython basierte und es daher etliche Bibliotheken gab, die nicht richtig funktionierten
    • Meine erste App habe ich auf PythonAnywhere gebaut. Manche Dinge laufen dort seit fast zehn Jahren
      Ich fand es wirklich gut, direkt in der PythonAnywhere-Webapp kleine Änderungen vornehmen zu können, und als ich mit GCP/AWS anfing, habe ich diese Funktion sehr vermisst
    • PythonAnywhere ist großartig. Wie für andere war es auch für mich der Einstieg in die Webprogrammierung
    • Als ich diese Nachricht hörte, musste ich sofort an Resolver Systems denken

  • Als ein Kollege den Satz „Python-Berechnungen werden in der Microsoft Cloud ausgeführt“ sah, scherzte er: „Offenbar schafft es nicht einmal Microsoft, lokale Python-Installationen unter Windows zu verwalten …“
    Aber es ist amüsant, sich vorzustellen, dass Microsoft das Problem der Einrichtung lokaler Python-Umgebungen tatsächlich endlich löst und Excel zum standardmäßigen Python-Paketmanager des gesamten Betriebssystems wird
    $ excelpip install fastapi==9.11.23
    Suche nach fastapi version 11.09.2023 …

    • Seit ich vor 20 Jahren Debians apt benutzt habe, warte ich darauf, dass Microsoft die Paketverwaltung unter Windows löst. Das ist nicht sarkastisch gemeint: Angesichts der Produktkomplexität von Microsoft und seiner Besessenheit von Abwärtskompatibilität schien Microsoft eher wie der Akteur, der Softwareverwaltung voranbringen könnte
      Ich dachte, sie würden tief in den Problemraum eintauchen und einen Paketmanager neu erfinden, der über das hinausgeht, was aus der Open-Source-Welt gekommen ist
      Stattdessen haben wir heute Windows Update, Windows Features, Microsoft Store, Software Center und winget. winget ist der von Microsoft erstellte Paketmanager für Windows, also das Tool, das man über einen anderen von Microsoft erstellten Paketmanager für Windows installieren muss
    • Mir kommt dabei ein solches Problem in den Sinn: Sollte Microsoft eine LTSC-Paketmenge einfrieren? Wie soll $GOV_AGENCY, die eine um eine Generation veraltete Excel-Version nutzt, mit der Welt zusammenarbeiten?

  • LibreOffice hätte die Zeichen der Zeit schon vor langer Zeit erkennen müssen. Grundsätzlich ist Python-Scripting möglich, aber es ist viel zu umständlich und unübersichtlich, und es scheint auch keine Roadmap für Verbesserungen zu geben.
    Dieselbe Warnung gilt auch für den Linux-Desktop und dessen Apps insgesamt. Immer mehr proprietäre Plattformen werden Cloud-basiert sein und bestehende Apps oft über Python-APIs um fortgeschrittene „AI“-Funktionen erweitern.
    Schade ist, dass viele Strömungen in der Open-Source-Welt zu stark versilot sind. Potenzial, das größer wäre als die Summe seiner Teile, wird verschwendet.

    • In vielen Fällen sind es nicht die fortgeschrittenen Funktionen, die Leute an Excel und andere proprietäre Produkte binden, sondern Dinge, die trivial wirken.
      Was mich an LibreOffice-Tabellen und Apple Numbers am meisten stört, ist der Umgang mit Kopieren/Einfügen nicht zusammenhängender Auswahlbereiche.
      Wenn man zum Beispiel in Daten mit 5 Zeilen und 3 Spalten die Zeilen 1 2 3, 7 8 9, a b c auswählt, kopiert und dann unter d e f einfügt, fügt Excel nur die ausgewählten Zeilen direkt aneinander an. LibreOffice und Numbers behalten auch die leeren Zwischenzeilen bei.
      Ich habe keine Einstellung gefunden, mit der sich dieses Verhalten ändern lässt. Umgekehrt kann Excel natürlich für Leute nervig sein, die die Abstände beibehalten wollen, aber ich wollte das fast nie, daher sind LibreOffice und Numbers für mich umständlich.
    • LibreOffice hat Python-Scripting praktisch von Anfang an mitgebracht.
      Dass es den Leuten nicht besonders wichtig ist, liegt daran, dass der beliebteste Anwendungsfall für Office-Suiten die Interoperabilität mit Microsoft-Dateiformaten ist.
    • ScriptForge ist einen Blick wert: https://help.libreoffice.org/latest/en-US/text/sbasic/shared...
      Zum Ausführen von Skripten innerhalb von LibreOffice wird der APSO Script Organizer empfohlen: https://extensions.libreoffice.org/en/extensions/show/apso-a...
    • Für mich sieht es eher nach dem Gegenteil aus. Python macht Scripting so einfach, dass Excel sich damit den Sargnagel einschlägt.
      Während die ältere Nutzergruppe, die nie eine Programmiersprache benutzt hat, altert und in Rente geht, werden Leute, die lernen, Python mit Excel zu kombinieren, am Ende Python bevorzugen. Es ist flexibler und besser erweiterbar.
      Außer für einfache Rechenblatt-Zwecke gibt es keinen Grund, Excel zu verwenden. Wenn jemand eine Tabelle verlangt, automatisiere ich die Erzeugung mit Python, damit ich sie nie wieder manuell anfassen muss.
    • LibreOffice hat viele andere Probleme, die zuerst gelöst werden müssen. Es ist zu langsam.

  • Enttäuschend.
    „Python in Excel ist derzeit für Nutzer verfügbar, die unter Windows den Beta Channel verwenden. Dieses Feature wird zuerst für Excel für Windows ab Build 16.0.16818.2000 ausgerollt und später für andere Plattformen verfügbar gemacht.“ [1]
    „Python in Excel ist in Excel für Windows verfügbar. Dieses Feature ist nicht in Excel für Mac, Excel im Web, Excel für iPad, Excel für iPhone oder Excel für Android verfügbar. Auf nicht unterstützten Plattformen können Arbeitsmappen mit Python zwar angezeigt werden, beim Neuberechnen von Python-Zellen wird jedoch ein Fehler angezeigt.“ [2]
    [1] https://techcommunity.microsoft.com/t5/excel-blog/announcing...
    [2] https://support.microsoft.com/en-us/office/introduction-to-p...

  • „Python-Berechnungen werden in der Microsoft Cloud ausgeführt“ – nein danke.

    • Das ist mir auch aufgefallen. Ich frage mich, warum sie sich für dieses Modell entschieden haben.
    • Ich wünsche mir dringend eine gute Python-Integration in einer Tabellenkalkulations-Suite, aber das hier werde ich nicht einmal ausprobieren.

  • Moment mal. LibreOffice hatte schon seit Jahren Python, niemanden hat es interessiert, und stattdessen wurde beklagt, dass man für „echte Arbeit“ 100 % kompatibles VBA brauche. Wo sind diese Leute jetzt?

    • Hier. Das Problem ist nicht nur 100 % kompatibles VBA, sondern dass man eine völlig neue API lernen muss, um VBA-basierte Tabellen zu erstellen, die nicht in Excel laufen.
      Wenn LibreOffice-VBA mit Office-VBA kompatibel gewesen wäre, gäbe es keinen Grund, irgendwo ein altes Windows-System weiter aufzubewahren.
      Wir machen das, um Geld zu verdienen, und niemand will Excel-Tabellen kaufen, die nicht in Excel laufen.
    • Es geht nicht darum, dass man sich schlecht fühlt, weil Excel mehr kann, sondern darum, dass LibreOffice weiterhin unbequem sein kann, weil vertraute oder zwingend benötigte Funktionen fehlen.
    • Wenn einer meiner Kunden LibreOffice nutzen würde, würde ich es gern verwenden. Aber niemand tut es.
      Ich arbeite unter Linux mit LibreOffice Calc, und da Excel Linux gar nicht unterstützt, wäre eine Kompatibilität schön, mit der ich Dateien problemlos an Kunden schicken kann, aber davon sind wir noch weit entfernt.
    • Wenn die Funktionen schlecht sind, nutzen die Leute es nicht.
      Wenn die Leute nicht wissen, dass es existiert, nutzen sie es nicht.
      Wenn sie etwas anderes gewohnt sind, verlangen sie genau das.
    • Das Problem von LibreOffice war, dass die Python-Unterstützung nur auf dem Papier existierte.