Slashdot Mirror
Microsoft Considers Adding Python As an Official Scripting Language in Excel (bleepingcomputer.com)
An anonymous reader writes: Microsoft is considering adding Python as one of the official Excel scripting languages, according to a topic on Excel's feedback hub opened last month. Since it was opened, the topic has become the most voted feature request, double the votes of the second-ranked proposition. "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))," the feature request reads, as opened by one of Microsoft's users.
The OS maker responded yesterday by putting up a survey to gather more information and how users would like to use Python inside Excel. If approved, Excel users would be able to use Python scripts to interact with Excel documents, their data, and some of Excel's core functions, similar to how Excel currently supports VBA scripts. Python is one of the most versatile programming languages available today. It is also insanely popular with developers. It ranks second on the PYPL programming languages ranking, third in the RedMonk Programming Language Rankings, and fourth in the TIOBE index.
The OS maker responded yesterday by putting up a survey to gather more information and how users would like to use Python inside Excel. If approved, Excel users would be able to use Python scripts to interact with Excel documents, their data, and some of Excel's core functions, similar to how Excel currently supports VBA scripts. Python is one of the most versatile programming languages available today. It is also insanely popular with developers. It ranks second on the PYPL programming languages ranking, third in the RedMonk Programming Language Rankings, and fourth in the TIOBE index.
I wonder how many more applications my boss can dream up for Excel that it really should never, ever have been used for?
... that won't result in increasing the attack surface. (eye roll)
Which has more power: the hammer, or the anvil?
So far it all seems to be very much against Python being used by Microsoft in Excel, granted it's still under 20 posts as I write this but considering it was the most voted feature on M$' site and I'm assuming those asking are themselves programmers, why so much negativity here?
The way I see it, if Excel uses Python, it gives people more incentive to learn it and that can translate into people able to use it in other programs that use Python.
Also, as someone who's had to troubleshoot broken VBA scripts on Excel, anything that can move us away from them is a win in my book.
Interesting all the comments regarding malware being distributed by Excel. Doing a quick search, the amount of malware distributed by Excel is on the rise.
I guess it comes from downloading pre-made spreadsheets - something I guess I'm immune to because other than an expense spreadsheet mandated by an employer, I don't think I've ever taken a spreadsheet where I didn't know it's creator personally. In terms of adding macros from other sources, the one or two times I've done that they've ended up being more work to get functioning properly than writing them on my own.
Could anybody comment on why this is such a big issue?
Mimetics Inc. Twitter
Python is a .NET language. Microsoft's IronPython compiles to .NET and uses the .NET framework instead of Python's regular packages. And VB.NET is not really "a new version of VB6" at all - it's a whole different language that's more like C# with its syntax altered to visually resemble BASIC. It doesn't behave like VB at all.
To all those predicting doom and gloom: Excel doesn't fit the role of an IDE, it fits the role of the debugger. Sometimes, much better than a debugger integrated in the IDE.
For those who know what we are doing, a spreadsheet is a wonderful tool for rapid prototyping business processes and gathering input from domain experts at the initial phase, when requirements are not at all clear and change quickly.
Having a modern language friendly to exploration and prototyping would be a welcome addition.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
Lua is more user friendly. It has less features, dynamic typing, starts at 1, doesn't care about whitespace, and was designed to be embedded within other things*. All those things are good qualities for people newish to programming.
*Which'll improve its security compared to Python. You can easily remove function/modules from the language and you can isolate parts of a script from each other. It's trivial to load a new module and prevent it from accessing the I/O system.
I have been wanting to be able to write C# to automate functions in an excel sheet.
You can easily do that since long time ago. There are even different alternatives (e.g., relying on a template or creating everything on-the-fly). If I have to communicate with MS Office and I can choose how to do it, I would develop a C# or VB.NET application rather than relying on VBA.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
Is it a good thing to help idiots to build more powerful Office-powered clusterfucks? This is like building a cheap and reliable cell-phone-triggered detonator: In the most technical sense, you made an improvement, but what if you consider what they're used for?
"When information is power, privacy is freedom" - Jah-Wren Ryel
My gut reaction is YES YES YES because I'm often stuck in Excel for... reasons... and don't like VBA much despite being pretty good at it.
But like you said, it probably won't be Python - it will likely be MS Python, stuck at some version forever and probably without nicey-nice stuff like the scientific libraries and package management that make it so useful.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
VB.Net is .Net first and VB second.
For example, if you type If foo = "1234" Then, it's doing some wonky-ass classic VB shit in the background (implemented in the Microsoft.VisualBasic namespace syntax shims) to allow variable foo to be an Int32 and still compare without a type mismatch. If, in C#, you try the same thing with if(foo == "1234") and foo is an int/Int32, it's going to flip its shit at compile time. But best of all, in either language, you can do If foo.op_Equality("1234") Then (or if(foo.op_Equality("1234")) in C#) and get the standard C#-style and .Net standard equality comparison operator functionality that bypasses the classic VB shims.
VB.Net is .Net first and VB second, only by means of the compiler handling special cases to fill in keyword functionality with Microsoft.VB shim code that works differently than bog-standard .Net. These shim functions generate some terribly expanded MSIL for things that look like they're simple language translation.
On a related note, you can add using Microsoft.VisualBasic to your C# code and start using things like Strings.Equals(object), for example, if(Strings.Equals(foo)), where foo is an Int32, like the previous example. This will use the "wonky-ass classic VB shit" string comparison, even in your C# code. With all of the MSIL performance gotchas that apply. .Net is an incredibly flexible ecosystem, and Microsoft strives to make things "easy" for newbies. But if you familiarize yourself with its inner workings, you'll quickly find that it's both every bit as complex as C/C++ and simultaneously capable of doing all of the same hideously unmaintainable performance tricks. It just makes them unnecessary most of the time.
Only one way to do anything.
Except that isn't true... for example you can format a string in several different ways. And then there is the different ways between 2 and 3.
Perl's simple string interpolation is much easier and straightforward.
Office suite + Python = OpenOffice. This is already a thing.
Weaselmancer
rediculous.
Exactly. Why anyone would use computer software for automation is beyond me.
VBA has static typing which Python does not.
(a) Python has strong typing, just dynamic rather than static. Most Python developers would tell you, and I would agree, that you should be testing your code with unit tests and assertions, and catching type errors at runtime is acceptable.
(b) Some Python developers, including the "Benevolent Dictator for Life" Guido van Rossum, feel that Python should have optional static typing, and it is now available. If you think it would help you, you can simply start using it.
Because it's optional, it's not built into the language compiler; it's a separate tool you run. You can automate running the tool if you like.
Python 3 supports "annotations" that are saved with your code; they do nothing by themselves. But a static analysis tool can use those annotations to do a static type check and give you a type error even before you try running your code.
The tool is called "mypy":
http://mypy-lang.org/
P.S. One of the reasons that Guido van Rossum decided Python needed optional static typing is that large companies such as Google and Microsoft were using their own hand-rolled static checking solutions; they would declare functions with special comments and then write checking tools that would parse the special comments. By building the type annotations into the language, Python has standardized on one particular way of doing the annotations. Now IDEs support it and people can share code. As the Zen of Python says: "There should be one, and preferably only one, obvious way to do it."
lf(1): it's like ls(1) but sorts filenames by extension, tersely