Microsoft maakt Python beschikbaar in Excel voor zakelijke klanten

Microsoft maakt de programmeertaal Python beschikbaar in Excel. Gebruikers kunnen hiermee gegevens in spreadsheets analyseren en visualiseren. De functionaliteit is beschikbaar in Windows voor Microsoft 365 Business- en Enterprise-abonnees.

De ontwikkelaar schrijft in een blogpost dat gebruikers Python-code kunnen toevoegen door ‘=PY’ te schrijven in de formulebalk van een cel. Hierdoor is Excel in staat om data te visualiseren, (voorspellend) te analyseren, op te ruimen of in te zetten voor machinelearning. Microsoft voegt ook Copilot-functionaliteit toe om automatisch Python-code te generen op basis van prompts.

De ondersteuning voor Python is tot stand gekomen in samenwerking met Anaconda. Volgens Microsoft hoeven gebruikers geen extra software te installeren. De code draait in een geïsoleerde Azure-container, die wordt afgesloten wanneer het bestand wordt gesloten. Het bedrijf benadrukt dat de gegevens na gebruik uit de Microsoft Cloud worden gewist.

Momenteel is Python voor Excel enkel beschikbaar voor klanten met een Microsoft 365 Business- of Enterprise-licentie. De ondersteuning wordt gratis toegevoegd, al komt er ook een add-on voor 24 dollar per maand die Python-formules sneller berekent. De ontwikkelaar heeft aan The Register laten weten dat ondersteuning voor Mac en browsers later wordt toegevoegd.

Bron: Microsoft

Reacties (47)

[i7x]

Geinig dat je python kunt gebruiken, maar wat een onzin dat dit via Azure moet. Compleet overbodig en zou op zijn minst optioneel moeten zijn (al zou ik zelfs dan niet kunnen bedenken waarvoor je het zou willen inschakelen tenzij je een aardappelcomputer gebruikt, edit: of web-based). Ik ga het wel uitproberen, maar het is wel een gare actie. En ze hebben ook net ltsc uitgebracht, dus zou mij niet verbazen als dit daarin ontbreekt.

[Reactie gewijzigd door i7x op 18 september 2024 13:11]

[Blokker_1999]

Omdat je dan Python moet installeren op de PC om het te kunnen gebruiken. En dat wil je ook niet altijd want dat vormt ook weer een beveiligingsrisico.

[i7x]

Ze kunnen gewoon micromamba oid bundelen met de Excel installatie. Of je het nu daarin draait of op een of andere Azure server maakt dan toch niet meer uit. En uiteraard netjes afgeschermd van de rest van het systeem. Nee, ik snap wel dat ze mensen Azure in willen forceren, maar enthusiast ben ik er niet over.

Voor web-based is het wel handig, maar het is prima mogelijk het optioneel via Azure te draaien (bijv als het web-based wordt geopend).

[GertMenkel]

Op welke manier is dat eigenlijk een beveiligingsrisico? Als iemand .py-bestanden kan uitvoeren op je PC, kunnen ze meestal ook .exe- of .ps1-bestanden uitvoeren. Moeilijkere malware komt binnen via gare infectieketens binnen Windows zelf.

Het containerisen van de code lijkt me al genoeg, maar dat kan Windows zelf ook; zie bijvoorbeeld de tijdelijke VM die Windows spawnt als je Windows Pro hebt en een .exe opent in een sandbox. Ik denk dat een snelle VM, à la Amazon Firecracker (die 150 VM's per seconde kan spawnen als het nodig is), net zo goed zou werken als het Azure-spul, als niet beter.

Ik denk zelf eerder dat hier gekozen is voor de makkelijke weg die ook nog eens een hoop geld oplevert en daarnaast piraterij van Office vervelender maakt.

[The Zep Man]

Op welke manier is dat eigenlijk een beveiligingsrisico? Als iemand .py-bestanden kan uitvoeren op je PC, kunnen ze meestal ook .exe- of .ps1-bestanden uitvoeren. Moeilijkere malware komt binnen via gare infectieketens binnen Windows zelf.

Dus iemand kan geen .py bestanden uitvoeren en geen andere eigen code draaien in een goed beheerde omgeving. Zelfs PowerShell kan in een goed beheerde omgeving dichtgetimmerd worden.

[Reactie gewijzigd door The Zep Man op 18 september 2024 12:48]

[The Zep Man]

Geinig dat je python kunt gebruiken, maar wat een onzin dat dit via Azure moet.

Niet iedere werkplek zal Python lokaal mogen draaien.

En ze hebben ook net ltsc uitgebracht, dus zou mij niet verbazen als dit daarin ontbreekt.

Van LTSC kan je verwachten dat die minder online wordt gebruikt, en meer als offline Officepakket. Voor lokale Excel kan je gewoon lokale Python gebruiken, uiteraard.

[84hannes]

Niet iedere werkplek zal Python lokaal mogen draaien.

Excel heeft al een scripting taal en draait allemaal andere code die je niet kan reviewen. Dus als Microsoft beloofd het goed te sandboxen, dan maakt het weinig uit of het lokaal of niet draait. Als Microsoft niet belooft het goed te sandboxen, dan is het sowieso een risico. Dus ik zie hier een poging om meer (nieuwe) functionaliteit cloud-only te maken, en daar word ik niet blij van.

[Reactie gewijzigd door 84hannes op 19 september 2024 12:38]

[The Zep Man]

Dus ik zie hier een poging om meer (nieuwe) functionaliteit cloud-only te maken, en daar wordt [sic] ik niet blij van.

De functionaliteit is niet nieuw en niet cloud-only. Verder wordt er geen bestaande functionaliteit weggenomen. Je kon en kan zelf prima Python lokaal draaien, met alle bijbehorende voor- en nadelen. Dat Microsoft dat officieel niet faciliteert past in de "cloud and mobile"-visie die ~10 jaar geleden was gekozen. Dat houdt niet in dat ze het lokaal gebruik op eigen houtje gaan tegenwerken.

Organisaties zien het draaien van code op de computer van een ander (die daarvoor wordt betaald) veelal als een lager risico dan het draaien van code op eigen computers. Voor hen zal de nieuwe functionaliteit aantrekkelijk zijn, ongeacht hoe veilig/gesandboxed het werkelijk is.

[Reactie gewijzigd door The Zep Man op 18 september 2024 12:50]

[WillySis]

Dit is een functie voor zakelijke klanten.

Als de Python toevoeging op een Azure server draait ben je wel verzekerd van een werkende installatie op elke computer binnen een bedrijf. Bovendien ben je ook verzekerd van een krachtige computer die de opdrachten uitvoert. Python is leuk en gemakkelijk, maar snelheid is niet de kracht van Python.
Binnen bedrijven worden vaak thin-clients gebruikt en met deze vorm van cloud-computing is de beperkte rekenkracht van de eigen computer dus geen belemmering.

Voor de normale consument of ontwikkelaar zou ik inderdaad liever een lokale verwerking zien. Misschien komt dat in een later stadium nog.

[Dreamvoid]

Er zijn erg weinig code-schrijvende power users die op een thin client draaien hoor.

[CivLord]

Maar misschien maakt de code-schrijvende power user op zijn workstation een Excel sheet die door een mindere god/ godin op zijn/ haar thin client gebruikt moet worden.

[WoutervOorschot]

Ik vind het enerzijds ook bijzonder, maar ik snap het wel. VBA staat er al bekend om (te) veel toegang te hebben tot het bestandssysteem en daarom een groot beveiligingsrisico te zijn. Laat staan als je lokaal python gaat runnen.

Dan had het mooier geweest als het lokaal in een container draait, maar dat is waarschijnlijk weer lastig stabiel te krijgen op alle vormen waarin excel kan draaien. Dit kan zelfs op mobiel/web/mac/linux draaien zonder enige lokale requirements.

Maar ja, je spreadsheet is dan wel afhankelijk van de cloud…

[B64]

Dit vervangt geen VBA macro's. Ter vervanging van VBA kun je tegenwoordig Office-scripts bouwen.

[lighting_]

Het is daarom maar beperkt functioneel. Alleen voor data analyse.

[Walrave]

Echt een fijne additie voor mensen die misschien geen andere toegang tot python hebben op werk. Ik ben benieuwd hoe het zit met alle libraries.

[Morrar]

Ze gebruiken Anaconda om virtuele omgevingen aan te maken en hiermee heb je dan een standaard set aan libraries tot je beschikking. Nieuwe installeren is volgens mij geen optie (geen magisch `%pip install` commando). Bron: Open-source libraries and Python in Excel - Microsoft Support.

Verder weet ik niet hoe blij ik wordt van deze ontwikkelingen... Enerzijds meer mogelijkheden voor de Excel gebruiker, anderzijds ook meer ruimte om totaal niet onderhoudbare code te verstoppen in rottig leesbare cellen en zonder fatsoenlijk versiebeheer. Ook tools om code een beetje fatsoenlijk te houden (black, pylint, isort) ontbreken en unit tests zijn natuurlijk helemaal niet aan de orde.

Persoonlijk zou ik dan liever zien dat mensen gewoon Python kunnen gaan gebruiken om hun data te analyseren i.p.v. dat ze dit via Excel gaan doen. Ook het opsturen van data naar een publieke cloud omgeving lijkt me voor veel bedrijven geen optie.

[Recursio]

Annvulling op wat je zegt:

Ik heb altijd als uitgangspunt: Excel is een endpoint en mag nooit op diens beurt als databron verderop in een informatieketen zitten, omdat er geen governance meer mogelijk is. Je immers hebt geen grip en dus idee welke aangepaste versies met welke kwaliteitscontrole zo een eigen leven gaan leiden, en wie welke versie gebruikt. Dan krijg je meerdere horloges die niet precies dezelfde tijd aangeven, en dan weet je niet meer hoe laat het is, juist omdat je meer dan 1 horloge hebt.

[StackMySwitchUp]

omdat er geen governance meer mogelijk is

Daar sla je de spijker op zijn kop.. want met Purview (en Sharepoint) kan dit wel, en 3x raden wat Microsoft samen met Copilot heel erg hard aan het pushen is..

[Reactie gewijzigd door StackMySwitchUp op 18 september 2024 12:17]

[Mellow Jack]

Ik kan me voorstellen dat het een oplossing is voor mensen die nu macro's schrijven. Wat je veelal ziet is een set aan Excel plugins (bijv. Reuters, Bloomberg en Morningstar) voor data downloads en dan macro's voor de verwerking.

Leuk de theorie dat je zulke mensen richting native python wilt pushen maar dan moeten ze een hoop extra uitzoeken (bijv. de werking vd api's). Klinkt altijd makkelijk maar is veelal een brug te ver

[The Zep Man]

Ik ben benieuwd hoe het zit met alle libraries.

Bron:

Open-source Python libraries

Python in Excel comes with a standard set of Python libraries provided by Anaconda through a secure distribution. Use these Python libraries to simplify your data analysis, find patterns and hidden insights, and visualize your data with plots.

Core Python in Excel libraries

The following open-source libraries are available with Python in Excel by default. They've been imported with the statements listed.

• Matplotlib. Import statement: import matplotlib.pyplot as plt
• NumPy. Import statement: import numpy as np
• pandas. Import statement: import pandas as pd
• seaborn. Import statement: import seaborn as sns
• statsmodels. Import statement: import statsmodels as sm

[edit]
Spuit 11 met @Morrar.

[Reactie gewijzigd door The Zep Man op 18 september 2024 11:58]

[meowmofo]

Gaat dit niet weer gewoon de volgende securitynachtmerrie opleveren?

[Bor]

Een goede vraag. We proberen al jaren bijvoorbeeld macro's aan banden te leggen omdat deze massaal misbruikt worden. Hoe gaan we dat bij deze python implementatie voorkomen?

[Blokker_1999]

Vanaf dag 1 uitschakelen en zorgen dat je goede processen hebt voor die mensen die toch een uitzondering wensen.

[Bor]

Dat is sowieso slim om te doen maar ook de mensen die een uitzondering wensen vormen potentieel een risico. Je moet dit daarom wellicht breder bekijken. Zijn de mogelijkheden bv beperkt tot een aantal commando's of kijken we tegen een redelijk brede implementatie aan?

[Reactie gewijzigd door Bor op 18 september 2024 12:07]

[divvid]

Een goede vraag. Waarom misbruiken die mensen macro's? Wellicht omdat de beheerders het nodig vinden zeer restrictief te werken?

Ik zeg niet dat je niks moet beperken, maar hebben jullie die vraag weleens aan de gebruikers zelf gesteld?

Misschien komt er uit naar voren dat medewerkers hun taak niet goed kunnen uitvoeren door allerlei restricties. Het is dan aan de IT om daarvoor een oplossing aan te dragen, b.v. door in een afgeschermde omgeving wél geavanceerde scripting toe te staan, mét een duidelijke uitleg wáárom IT de standaard tools afgeschermd heeft ipv alles rücksichtslos af te sluiten.

[Honytawk]

Het misbruik komt in de vorm van malware dat verspreid wordt.
Dit komt niet van de gebruikers, maar van malafide third parties en heeft dus niets met restricties van de gebruikers te maken.

[Reactie gewijzigd door Honytawk op 18 september 2024 14:36]

[divvid]

dan is mijn vraag: hoe komen die malafide third parties überhaupt in je excel omgeving terecht. Ergens upstream gaat dan al iets mis in de security.

[familyman]

Los van malware, is veel vba code een omzeiling van data bronnen en -tools, die uiteindelijk je hele it omgeving onbeheersbaar maken.

[divvid]

dus als ik je goed begrijp zeg je dat je met VBA de security van je databronnen omzeilt? Leg dan eens uit dat de IT in een groot ziekenhuis zelfs cursussen VBA in Excel geeft voor de data analyse? Wat kunnen ze daar wel, dat in jouw omgeving blijkbaar mis gaat? Ik volg 'm niet.

[familyman]

Nee, de beheersing ervan

[i7x]

Als ik het zo lees zie ik niet echt hoe dit misbruikt kan worden, zeker niet in de mate van vba. Je kunt wat berekeningen uitvoeren en met een aantal libraries de boel wat visualiseren/analyseren. Niet alsof je zomaar toegang hebt tot andere files op het systeem oid. En verder zou ik geen nieuwe tooltjes meer ontwikkelen met vba, zeker niet welke je nog enige tijd wilt blijven gebruiken--niet echt een houdbare oplossing inderdaad. Je kunt mensen leren beter gebruik te maken van power query, Office Script, eventueel wat Power Automate, en nu dus ook wat python. Dan kun je waarschijnlijk al een heel deel goed opvangen. Ja, soms werkt het wel wat minder ideaal/snel, maar dat gaat met de tijd wel verbeteren, waar vba overeind houden enkel moeizamer zal worden.

[lighting_]

werkt in een gesloten omgeving.
En alleen voor analyse
Het is ook geen full blown Python

[Reactie gewijzigd door lighting_ op 18 september 2024 12:59]

[Niet Henk]

Het draait niet lokaal. Je submit je code + inputs naar Microsoft, je krijgt de output terug. Daarom heeft het praktisch weinig security implicaties, buiten dat je er je Excel-data naar Microsoft mee kan sturen. En dat kan Excel al op veel manieren (o.a. Onedrive).

Dit is naar mijn mening ook een groot nadeel, want zodra je iets geavanceerders wil (met externe/grote bestanden werken, computationeel intensieve dingen, etc.) heb je een probleem. Maar het lost wel het security-probleem op (en ook het compatibiliteits-probleem, want op deze manier kan je hiermee makkelijk op Android/iOS/webbrowser werken).

[familyman]

Als je iets geavanceerders wilt, moet je niet naar excel als je oplossing kijken

[GertMenkel]

Python code used by Excel runs on the Microsoft Cloud with enterprise-level security as a compliant Microsoft 365 connected experience, just like OneDrive. The Python code runs in its own hypervisor isolated container using Azure Container Instances and secure, source-built packages from Anaconda through a secure software supply chain. Python in Excel keeps your data private by preventing the Python code from knowing who you are, and opening workbooks from the internet in further isolation within their own separate containers. Data from your workbooks can only be sent via the built-in xl() Python function, and the output of the Python code can only be returned as the result of the =PY() Excel function. The containers stay online as long as the workbook is open or until a timeout occurs. Your data does not persist in the Microsoft Cloud.

Ik betwijfel het, met die beschrijving. Tenzij ze Azure weten te hacken vanuit zo'n Python-container, maar dan is het vooral een nachtmerrie voor MS.

[c.titan]

Heb al gebruik kunnen maken van de beta versie in de beta channel.
Helaas is het niet mogelijk om data op te halen door een interne API aan te spreken, wat wel mogelijk met de Anaconda plugin voor Excel.
Echter weet ik niet of het slim is om Anaconda company wide beschikbaar te stellen vanuit security perspectief.

[E-Flex]

Oei, mijn "nerdhart" gaat hier heel snel van kloppen, mijn "managementbrein" denkt, "oh jee, mogelijk security en onbegrijpelijke code"

[maali]

hmh, eigenlijk niet des Microsofts... waarom niet hun eigen F# scripting + .NET?
en is het niet zo dat juist voor excel achtige data analyse (veel collection iteratie, me dunkt) dat python niet al te vlot is tenzij je numpy of pandas of whatever gebruikt?

[Anoniem: 718943]

Nou ja, Python wordt juist heel veel gebruikt in de wetenschappelijke wereld voor data analyse en verwerking, ook zijn er tal van AI modules beschikbaar. Dus wat dat aangaat lijkt het mij wel een logisch besluit. Python is niet de snelste taal, maar zoals je al aangeeft zijn er een aantal defacto standaard modules die wel snel met grote bakken data overweg kunnen.

[bantoo]

F#/C# etc zijn geen fantastische scripting talen. Ze zijn er niet echt voor opgezet. Excel heeft wel een .NET Framework plugin API waarmee je extensies kunt maken. Je kan hierin bijvoorbeeld knoppen aan de ribbons toevoegen, zijpanelen, of nieuwe functies definiëren. Echter is dit niet geschikt voor de gemiddelde Excel gebruiker. Een Python promptje is super handig voor de gemiddelde non programmeur, dezelfde doelgroep als het VB systeem effectief.

[Dreamvoid]

Je kan nu al in javascript macros schrijven, maar daar wordt niemand erg blij van: minder krachtig dan wat VBA kan, en de meeste interessante libraries voor Excel-gebruik zijn voor Python.

[Recursio]

@IdrizV:

De ondersteuning wordt gratis toegevoegd, al komt er ook een add-on voor 24 dollar per maand die Python-formules sneller berekent.

>>> De ondersteuning wordt gratis toegevoegd, al komt er ook een add-on voor 24 dollar per maand die Python-code sneller uitvoert.

[BaatZ]

Moet er niet aan denken om python code in te kloppen in die formulebalk. Doe mij maar een IDE met code completion en kleurtjes voor bekende words.

[Bark_At_The_Cat]

Je moet voor de grap eens een Power Apps Canvas-applicatie bouwen als je in een Office 365-omgeving werkt. Dat is dan wel geen Python, maar Power FX (een aanpassing/uitbreiding van de Excel-formuletaal). Dan bouw je alles in een formulebalk die je gelukkig kan openklappen, heeft kleurtjes en IntelliSense, maar het wordt alsnog een grote chaos van formule acter knopjes, acties, etc. etc.

Het zou wel fijn zijn als Power Apps / Power Automate ook mee kunnen leunen op Python op Azure zonder dat je daar een subscription voor hoeft te configureren.

[Reactie gewijzigd door Bark_At_The_Cat op 18 september 2024 13:49]

[bush]

co-pilot kan de code genereren, dat hebben ze gisteren laten zien op een linkedin event https://www.linkedin.com/...780403867443202/comments/

[beerse]

Misschien wel een fijne toevoeging maar jammer dat dit expliciet voor python is. Het zou mooier zijn als ze een wat meer universele interface gemaakt zou den hebben.

In het verleden hebben we met de diverse basic varianten in msOffice ook genoeg problemen gehad. Ook andere talen in vergelijkbare pakketten zorgden voor de verkeerde lock-in of lock-out. En veel van die talen zijn een eigen leven gaal eiden en hebben nu allemaal een reden om niet gebruikt te worden.

Van microsoft had ik eerder een powershell of misschien wel een C# interface verwacht. Met voor C# het voordeel dat de code gecompileerd moet worden en zo als blob in het document kan worden opgenomen en liefst ook met hash of key of zo vast worden gezet of centraal worden bijgewerkt.

UIteindelijk hoop ik dat de installaties zodanig kunnen worden ingesteld dat deze interface ook kan worden uitgezet en geblokkeerd.

[djwice]

Wow, dat is een slimme zet. CoPilot is namelijk ook python driven, die genereert nu als agents in Python om taken voor je uit te voeren die hij normaal niet kan. Hij genereert dan naar aanleiding van je prompt een script en voert dat script uit zonder extra tussenkomst van de gebruiken.

Bijvoorbeeld als je een bepaalde data analyse wil doen.

Dus nu Excel ook python kan, kan CoPilot agents genereren die in je Excel opgenomen kunnen worden die de data analyseren. Zeer sterke combi.