Python as an Excel scripting language
Let us do scripting with Python! Yay! Not only as an alternative to VBA, but also as an alternative to field functions (=SUM(A1:A2))
Daniel
shared this idea
Wow.
Thank you to all those participated in our survey. What an amazing number of responses, many of them with very deep content. We’re processing the over ten thousand responses(!), and already appreciate the time so many of you took to answer with passion and experience.
Please know this survey is used to help influence various topics – both on Python as well as other related topics that the comments started to bleed into. Given the passion, I want to be clear this remains an area of exploration for us, without any specific timeline.
We’ll provide updates as we progress on this feature request.
Thanks!
Ashvini Sharma
Lead Program Manager
Excel
493 comments
-
Muhammad Raza Cheema
commented
I work in the Manufacturing Industry and when we can't find a calculation in commercial software we turn to Excel and make a spreadsheet. One of the main reason I don't like Excel is how limited the VBA is regarding data integration. I learned Python to look for other solutions and I love Python now. It has everything for me and now I can create calculation spreadsheets without even thinking about excel.
No one asking to remove VBA support as a lot of businesses rely on it. Just add python support along with VBA and give users a choice. ANSYS has done it by using IronPython project.
-
Nick Hemsing commented
For those that are defending VBA, this isn't about VBA or replacing VBA with Python. Too many business and finance users are deep into VBA and I think Microsoft is well aware of the necessity of VBA to those users.
However, Excel is also used for sciences, including data science. It is also used by business users like me that use Python to manipulate large data sets. Having Python (or R) as another scripting language for Excel allows those users to integrate their algorithms with the features of Excel. Excel can, for those users, then take advantage of an expansive list of packages for gathering and manipulating data to then present in or prepare for further review, in their spreadsheets.
In my field, retail, having my python algorithms to run in Excel for my other business users would be incredibly powerful. I could access API's from data sources that are not available through Get & Transform or VBA. As it is, with new packages being created to get and manipulate data in Javascript, I'm starting to look at Google Sheets. VBA is just too clunky and the new people coming from college know R or Python. Javascript is a shorter hop from them than VBA.
-
Adriaan Riet
commented
@Joe Bockover I really don't think you need to fully understand interpreters or third party modules to use python, any more than most business professionals understand the DOM. Also, python isn't a one-trick pony, so you can't pretend it "belongs" in one environment. I'm still hoping (maybe) one day to get this feature, so I disagree with those leaving "forever" that we've All Moved on, though. I found python far easier to learn than VBA, but maybe that was from the good documentation and decent IDE.
-
jay zh
commented
@Jamie Totally agree with you. Those chose to ignore programming can still use Excel just fine, maybe with limited functionalities. However, for serious Excel users, programming is inevitable. For example, my work involves with lots of data and computations. Without a programming language's help I will be 1000 times slower and potentially not able to carry out any work. I chose to use Python to work with Excel because it's just so much better than VBA in all aspects.
-
Jamie
commented
@Joe Bockover you're comment applies equally to VBA. The vast majority of Excel users aren't interested in VBA either. But those who are interested in programming in Excel would I'm sure prefer an environment that hasn't just been left to gather dust for years. I know I only use Excel where the end user needs a convenient input format, and everything else happens in python/javascript. Maybe that wouldn't be the case if python were built-in.
-
Joe Bockover
commented
Dear python folks who want to say goodbye: Goodbye. You won't be missed. And Excel/VBA will live on just fine without you, considering so many business processes are deeply rooted and dependent on it.
I'd encourage you to remember: the vast majority of business professionals working in Excel have no interest in learning how to code beyond macro-level. Asking people to embrace python, JavaScript, or similar--with all of the overhead involved (understanding interpreters, runtime environments, third-party modules that don't align with the Office DOM, etc) is kind of ludicrous. Get over it and save python for science (data, chemistry, etc) where it belongs.
-
Nichlas Dyhr Hummelsberger
commented
I agree with Craig. Those of us who once cared has found the solution directly in Python and have moved on.
It's a bit sad to see, as MS seems to be at the forefront of python development in other areas. But I guess Excel is dead left on life-support.
To anyone who needs real number crunshing I can recommend learning python, numpy and pandas. You will be able to do anything with data that you dream of, and can still deliver the result in pretty excel with the XlsxWriter module.
-
Craig
commented
Well you've done it Microsoft. You took so much time on this that I've learned how to get what I need from open source Python libraries, and I love it! Thank you for forcing me to learn other (better and free-er) technologies. Goodbye Excel and VBA! We had some great times, but you're struggling to stay relevant in 2020.
-
Anonymous
commented
It makes almost 5 years that microsoft promissed this feature. I think they will never release it (a python api like in libre office is not a huge work for microsoft???). The haven't released any beta version!
-
Anonymous
commented
It would be great to enable it with a similar approach as PyXLL does:
https://www.pyxll.com/features -
Rodrigo Merlo
commented
KT,
I agree 100% on everything you just said, this is never going to happpen.
I have a love-hate relationship with cloud-based at the moment, but won’t waste anyone’s time ranting about it here.
-
KT
commented
Microsoft is too busy trying to convince Excel users that a web based JavaScript written Excel single page application is as good as a stand-alone Excel app.
No one at Microsoft gets a promotion for fixing VBA, rewriting it or replacing it.
That's the reason why long lived Microsoft legacy products like Excel only get tiny micro-features and tiny bug fixes version after version.
A reskinned UI with new blocky graphics is not a feature and an insult to paying customers.
The only truly new Excel feature since Excel 2003 is changing from 65000 rows of data to millions of rows of data. The rest of better data connections, faster recalc, fancier graphsand charts are micro-features.
Treat each new feature as "Is it a core feature, or is it just a rewrite/add on to a peripheral feature?"
You will find that 99% of the features are add-ons, rewrite of peripheral features, reskinning UI, 'better tooling' or other micro features.
So What's the compelling feature difference between O365 Excel and Office 2007?
A network disk in the Cloud is not a compelling new feature.
Expect Excel versions to be pumped out every 2 years to retire and end-of-life the versions that can be had without a $10 a month subscription.
If anyone asks, mention being burned by Silverlight and Lightswitch.
Expect the 12 month announcement that your favorite cloud enabled feature will be removed with no replacement and no migration path. It's in the MS Cloud documentation that any feature may be retired with a 12 month announcement without a migration path and without any replacement software.
Lesson learned from past episodes is to not build any big business logic or workflows on those products since you rest assured will be throwing away 100% of the development costs and 100% of the company wide training you spent on them.
-
S. Stockton
commented
@Roy - See also: OpenPyXL, xlwings.
-
Roy
commented
Sure it is. If I want to pay twice for it what I do for Excel itself.
Not today please.
-
Tony Roberts
commented
It is already possible to entirely replace VBA with Python for writing user defined functions, real time data functions, macros, ribbons, menus etc should take a look at PyXLL. Take a look at https://www.pyxll.com/ for details.
-
abcd
commented
Looks like they went with TypeScript instead of (or perhaps in addition to) Python.
https://www.youtube.com/watch?v=bNbu5ANUeAw -
Anonymous
commented
So imagine if azure notebook service can control excel? All of the kids learning python in college can communicate with the 1 billion excel users by coding in their notebook and outputting to excel, the entrenched and rightfully undying format. VBA can’t touch it. And even python can’t touch Julia, which can process data with C-like efficiency.
Excel needs vba to support the legacy framework, python to support up and coming frameworks, and Julia to support future state I state frameworks. If it wants to stay relevant.
-
IM
commented
Personally I'm not fussed if it's pyton or whatever, but VBA and particularly the built in editor for excel macros desperately needs an update.
MS have the wonderful VSCode, so a marrying of that and excel would be excellent.
-
Rodrigo Merlo
commented
I think it’s fair to say that anyone voting here pretty much knows VBA so that argument is invalid.
It’s extremely short-sighted to think that the group of people that is voting on something like this merely flat out refuses to “just learn VBA”
Truth is that python has a full ecosystem for scientific computing that you could not dream to implement in VBA.
What you are saying is akin to walking up to a MATLAB user and saying “why are you paying for this, just learn VBA”
In fact I think that a python enabled excel would actually serve as a nice replacement for MATLAB/Anaconda in a bunch of applications.
-
Roy
commented
The absolute chief value to Python as a scripting language would be MS completely surrendering the world of Excel scripting (perhaps including a little more than the obvious macros and UDF's) to an outside agency.
MS has not updated VBA, except for small fixing and accomodation of the fact of some additional features, for a very long time and actively plans to never do so. This is not a way they intend to spend money or other resources. Period.
If they do, and one considers the fact that Excel MUST have a macro language, and the fact that they might like to move forward with versions of Excel that actually drop supposrt for VBA itself (though many would still have versions it works in), their obvious role would be to maintain entry to Excel's data, and objects in general, publishing and updating as time passes, and EVERY programming language, open source or owned, that wished to, could build out itself to be a scripting language for Excel, in whole or in part.
The language owner would then be the one responsible for all the work and cost. It would be responsible for making it work and fixing bugs or deficiencies. For deciding how strongly to support it. For updating for changes in Excel's underlying progrramming and therefore the access into it. For adding functionality in general, or for explaining why only some aspects were being used by the language, not all. For arranging cooperation between it and other languages a programmer/spreadsheet developer might wish to use in conjunction in their workbook.
Etc.
Which, for the love of God, is how we should want it. (Always given that MS is clearly absolutely committed to NOT ever spending a dime on a seamless, "internal" solution to the need.)
This would also permit one to learn and use VBA, as long as it lasted. As changes in Excel broke aspects of it, and no fixes came along, it would be less and less useful, but that seems something MS doesn't mind anyway, so replacements are needed... anyway.
Python itself? Yeah, today, and for a lifetime for current programmers in it (still have a TON of COBOL programmers collecting consutling fees at the age of 85), strong and popular. But tomorrow, maybe a new language buds off a current one, or is conceived fresh for the future, and it too can be used, if the developers, paid or contributing, care for it to be.
So basically... it is NOT simply a gripe by lazy nerds to have their own "pet" thing done.
(Although, sure, there's that too. But it's a tiny component!)
It's the obvious future and a general, not specific-to-Python, solution, like above, on MS's part is the true gain to be pushed for here.
Although... it's a stunning number of votes compared to the number for other top suggestions!
Consider too, the "thousand flowers" that could bloom if suddenly every Python programmer could write add-in's and UDF's, ones that sing, not clomp their ways to the end of the task. Python's been a thing for a generation now, so there are a LOT of programmers using it. Even without MS's cooperation, there's a lot of Excel you can currently do with it. (So it's a better frontman than, say, COBOL or GW Basic.)
But "way more nice to have than anecessity"? Only if you limit the thought to just implementin Python itself and really changing nothing else. And that's somewhat arguable anyway even if VBA is rock-solid.
Also, as I say, with the responsibility to make languages work off their shoulders, maybe Excel would attack to "basic core functionality" issues we all want instead of just not doing some because they don't want required parallel work to do like making VBA not just accomodate re-written code, changed functionalities, and the altered object model, but be rock-solid and seamless for even a casual user of VBA (any break in the chain from casual user to competent to skilled vis-a-vis VBA risks permanently breaking movement up in skill).