Python in Excel goes live – but only for certain Windows users Office power users, rejoice: Python in Excel is now generally available - provided you have the right license and machine. First teased last year, the new feature allows Excel users to run Python scripts inside workbooks for analytics and other purposes. Redmond announced the official release of Python in Excel for Windows …
I guess this is to deprecate and remove VBA.
So on the one hand we get to swap one massive security hole for another one, while on the other Microsoft gets to reduce their workload while charging more.
On the gripping hand, it also means LibreOffice can now legally implement the same scripting language.
OfficeScript is the thing that is to deprecate and remove VBA.
There is nothing here that you can't do in pure Excel formulae. In theory anyway. It is pretty easy to bring the entire system to its knees if you use all 1048576 rows, whereas if you pull it into Numpy do your work there and spit out the results, it will likely work just fine.
Also there's some charting options that aren't easily available on Excel.
Funnily enough, yesterday I couldn't track down a problem in a very large excel spreadsheet which was supposed to be processing several sets of loading data for a finite element model (each set of data had over 0.5 million items.) In the end, I gave up and processed the data in a python script instead..... (probably what I should have done to start off with, but when you're given data in excel, it's easy to temporarily forget there are other options....)
The scourge of 2nd line application support desks.
Somebody (non technical - not a developer) creates a rats nest of a crosslinked workbook using lots of googling to figure stuff out Only they use it and know it. They leave the business and a person inherits their role - and the Excel Workbook. Then something needs tweaking to accommodate a change, and the new person fiddles with part of the chain and breaks the whole thing. Department boss demands that support fix it quickly. Look forward to hearing about this when Excel transitions.
I'm trying to think of specific examples as Python is notoriously cautious at introducing new syntax and has a pretty good track record of backward compatibility, some unnecessary errors in the move from Python 2 to Python 3 aside. Changes in the last decade or so: async and match; the walrus operator and the type hints noise. Code from 2.7 should run largely unchanged on Python 3.12 and the forthcoming 3.13. I run CI for a couple of projects for a wide range of versions and syntax changes are rarely a problem for existing code. It's usually good practice to avoid the new stuff in production for a couple of releases: async is still ironing out the creases, and while the match stuff could be very useful in some use cases, it's still quite slow.
However, I'm not a huge fan of the change to yearly releases and the relatively quick deprecation of older versions, which are likely to be running on millions of machines around the world. But I think this is the case for other languages where too many people seem to have forgotten sys admin wisdom of leaving things running wherever possible.
> and has a pretty good track record of backward compatibility
Python has a pretty good track record, true.
Python packages are a very, veeery different matter.
The amount of time I wasted fixing old, or even abandoned, python packages, where the maintainer thought it would be a swell idea to pin one specific version of a dependency as a requirement, even though nothing in the package actually relies on that specific version of that dependency.
And those are still the easiest to fix, usually I just need to update an old pyproject.toml or setup.py to make pip stop complaining.
It gets alot worse, when suddenly a package relies on some C-libraries, and there actually is a reason that dependency was pinned, so I have to install an old version of the package, which requires an old version of the lib to work, but the system no longer has that lib, because its 10000 years old...
Oh yeah: pinheads! The version pinning stuff can be very annoying: pinning really should be limited to deployment unless there are breaking changes to consider, in which case >= and occasionally <= are you friend. Had one guy submit a heap of PRs, including pinning and complete refactoring of tests away from the code… and nothing else of substance.
Packages needlessly dropping support for older Python versions is also very annoying.
Python 3.7 to python 3.8... removal of nullptr broke a lot of shit. That's one example that came to mind (because it affected applications I needed to use... had to build LibreOffice with its own python interpreter)
Also, regardless of compatibility, any x.x.y upgrade is going to break all your modules anyway.
Not really, for years there have been successful examples of safe Python sandboxes running "untrusted" code. But the runtime is key and the VBA runtime always had too many privileges, as well as being very slow. I've not looked deeply into the details, but in the request to add support for the feature to my library, from a Microsoft employee incidentally, was all running code on Azure.
So, embedding a scripting language inside an excel file that can get emailed to you
Trying to rerun last years close-fiscal-year excell sheet, only to end up in pip-hell
excel wizards trying to outsmart themselves by writing extremely clever python scripts that drag in excel sheets that use python scripts
People who don't understand python seeking help from python developers who dont understand excel
O(N^3) python code that works awesomely for 20 line 50 row spreadhseets being applied to 5000 line 200 row spread sheets
And probably the clincher, excel wizards starting to migrate VBA excel files to python files and stopping part way so you know have an excel/VBA/python monstrosity
i think this is a really clever ploy from M$ who will soon be announcing an Excel consultancy business ....
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
