20 comments

[ 0.28 ms ] story [ 44.2 ms ] thread
This could be one of those things that definitely grabs developers attention in a good way. I disagree it needs to be for all Office apps - if it was just Excel and Access that would be plenty.
They should consider adding it to azure functions too!!
It's coming. The 2.0 runtime and the new out-of-process model required some changes, which are being tracked here:

https://github.com/Azure/azure-webjobs-sdk-script/wiki/Azure...

But you _can_ use Python right now in the stable runtime--it's just not as nice or full-featured, because of the way the 1.x runtime works.

(I work for Microsoft on an unrelated team, and I too am waiting for Python to be back, hoping for 3.6 and asyncio)

On the one hand this would definitely result in learning me some Python... on the other hand I am somewhat sorry it is not Perl.
Why would you prefer Perl for it?
I find it easy to express myself in the language and I think it is a good fit for the problem domain at least in terms of what Perl was traditionally good for, "glue" and data processing.
I think the idea of Perl in Excel is terrible, but it's still less terrible than downvoting an opinion
I honestly feel that Lua would be a better fit, since the Lua table maps pretty nicely to Excel cells... but I'm sure there's some reason that it would unsuitable?
I'm guessing the popularity of Python is why they're going with it. Quants and other power users are starting to drop Excel and moving on to Python, so they figure they might be able to keep some market share this way.

Otherwise I'd guess they'd try to push one of their .net languages, probably C#.

I live in ohio and it's 6 degrees outside I'm aloud to be mean in the morning:

https://stackify.com/popular-programming-languages-2018/

Yeah, who cares about some dumb list? The point is why can't we put any - and all/other - of these languages in the Excel runloop by now? You say Python, I say Lua, someone else says Go.. seems to me that all of the above oughta have a go at it. Excel is freakin' everywhere.
Always been a mystery to me, why they have never added .NET language support. 16 years and counting...
They have had .net support for many many many years although not as a scripting language, but you have been able to write your "macros" in .net for a long time, deploy the assembly to a web server and have excel, word, etc download the code from there there. Its a little harder to deploy that an inline macro but gives you a central location to update the code instead of trying to tracking down and update all the copies of your word/excel documents.
Do I need to remind you of the org chart? ;)
In case people aren't aware - you can use any language with COM bindings to script Excel/Word/PowerPoint/Adobe/etc from outside the application.

Python has pywin32. Usually I have a python prompt and Excel open side by side and highlight cells I'd like to modify in Excel and then switch to Python to run the appropriate functions.

The COM API can be used interactively (attach to an existing instance or launch the GUI) or automatically (launch an Excel instance but turn off visibility).

> from outside the application.

And that's the thing holding back adoption, I bet.

>> from outside the application. > And that's the thing holding back adoption, I bet.

That, plus the painfully verbose and unintuitive COM API. If they add a Python layer to Excel I would really like to see COM replaced with a simpler (pythonic?) interface.