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.

11 of 181 comments (clear)

  1. With Excel + Python, by olsmeister · · Score: 5, Insightful

    I wonder how many more applications my boss can dream up for Excel that it really should never, ever have been used for?

    1. Re:With Excel + Python, by networkBoy · · Score: 4, Interesting

      nah, semicolons are there no matter what.
      Changing editors can *totally* mess up the whitespace.
      Yes, literal spaces will help, but all it takes is one idiot/mistake and the codebase is pooched.

      That and the fact that 2.x code can't run virtually unmodified on 3.x interpreters really pisses me off. Perl, for all its warts, just needs

      use perl4;

      at the top of the file right after the crunchbang and you're good to go with an old as dirt script on the newest interpreters.

      --
      whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
  2. Yeah.... by Lab+Rat+Jason · · Score: 3, Funny

    ... that won't result in increasing the attack surface. (eye roll)

    --
    Which has more power: the hammer, or the anvil?
  3. Why is /. so negative? by substance2003 · · Score: 4, Insightful

    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.

    1. Re:Why is /. so negative? by Gilgaron · · Score: 3, Interesting

      Sometimes I mock things up in Excel before handing it to a developer to code... being able to use Python in the mockup would be pretty awesome and give me more experience in a coding language that is actually widely applicable... seems like a win-win.

  4. Re:Curious news by Anonymous Coward · · Score: 4, Interesting

    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.

  5. The ultimate debugger (for non-devs) by TuringTest · · Score: 4, Interesting

    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.
  6. Re:C# by CustomSolvers2 · · Score: 4, Informative

    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.
  7. Re:Python in Excel... by MightyYar · · Score: 4, Insightful

    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.
  8. Re:Curious news by Anonymous Coward · · Score: 3, Informative

    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.

  9. Um...OpenOffice anyone? by Weaselmancer · · Score: 5, Informative

    Office suite + Python = OpenOffice. This is already a thing.

    --
    Weaselmancer
    rediculous.