4 ms·

One issue with embedding Python is that it's difficult to sandbox - to securely limit what the embedded runtime, and hence (potentially malicious) custom functi

One issue with embedding Python is that it's difficult to sandbox - to securely limit what the embedded runtime, and hence (potentially malicious) custom functions, can do: > [The Python developers'] standard answer to "How do I sandbox Python code?" has been "Use a subprocess and the OS provided process sandboxing facilities" for quite some time. [1] JavaScript, OTOH, is designed to support secure in-process sandboxing. Other languages with such support do exist (e.g. Lua), but JavaScript is by far the most widely known. [1] https://mail.python.org/pipermail/python-dev/2013-November/130145.html https://mail.python.org/pipermail/python-dev/2013-November/1...

willhslade 8y ago
I think this is the real reason why we will never see Python inside Excel. The other, minor, reason is that Guido has pretty much pooped all over the idea of backwards compatibility in Python, which is pretty much integral to Microsoft's vision.
Quenty 8y ago
Other benefit is the web version can potentially run the javascript in the browser instead of waiting for a network call. Not sure what the security implications are here.
AnIdiotOnTheNet 8y ago
Didn't and doesn't stop them from using VBA, which of course is already used by malicious entities everywhere, so if they're unwilling to stop supporting that then why not let unsandboxed python work?
brudgers 8y ago
Good point. Another architectural difference between the languages is that Javascript is a [relatively] small language with a long history of working with external API's [i.e. the browser]. On the other hand, Python has extensive standard libraries that would require alignment with Excel. For example, how does csv.reader integrate? It looks like a can of "do the obvious thing" worms and a mountain of unexpected results and documentation. Mostly, I think it comes down to Python being designed as a systems language rather than a scripting language. Integrating Python would seem to mean either a weak security model or a special (subset) version of Python. Neither is really going to meet the fat part of the Bell Curve...people who just want to get things done in Excel. Applying a 'browser abstraction' to Excel is probably better than applying an 'OS abstraction'. Anyway, JS has been a part of .NET and VS since JScript. Python, not so much.
- bakery2k 8y ago
  > Python being designed as a systems language rather than a scripting language Interesting - I hadn't really noticed how pronounced this dichotomy within dynamic languages is. On the one hand there are small languages designed for embedding and sandboxing (e.g. JavaScript, Lua, Tcl) and on the other hand, larger, more general-purpose languages (Perl, Python, Ruby). I always assumed that a dynamic language could work well in both contexts, but in fact, most lie fundamentally on one side of the divide or the other. Only JavaScript, due to its immense popularity, has really managed (with Node.js) to expand from the first category into the second. If Python were to be embedded in Excel, it would be expanding from the second category into the first. As you mention, to do this safely it may be necessary to create a special (subset) version of the language. Matz, the creator of Ruby, is trying to take his language in this direction with mruby [1] - a "lightweight implementation of Ruby complying to (part of) the ISO standard". But, will these subset versions ever be popular? They necessarily leave the majority of the language's ecosystem behind - and knowledge of the full language will not necessarily transfer directly to the subset. Can a subset of an existing general-purpose language, even a widely-known one, compete against other languages that are specifically designed for safe embedding? More generally, is it possible for a dynamic language to work well on both sides of the divide, or must all (even brand-new) languages choose one side or the other? [1] https://github.com/mruby/mruby https://github.com/mruby/mruby
  - brudgers 8y ago
    I think the more important divide between language communities may be between consensus and individual authority. Python's BDFL and Javascript's standardization lie at opposite ends of the spectrum. To caricaturize: Javascript is the intersection of what many interested parties can agree on. Python is the union of anything that struck a single individual's fancy over the course of decades. The rise and fall of functional programming as Pythonic is a case study of the language community's arbitrariness (if Python2 v Python3 wasn't enough). As an aside, Ruby avoids this because it's vision is not tribal. Principle of least surprise allows for differences among programmers. Pythonic/unPythonic doesn't.

willhslade 8y ago

I think this is the real reason why we will never see Python inside Excel. The other, minor, reason is that Guido has pretty much pooped all over the idea of backwards compatibility in Python, which is pretty much integral to Microsoft's vision.

Quenty 8y ago

Other benefit is the web version can potentially run the javascript in the browser instead of waiting for a network call. Not sure what the security implications are here.

AnIdiotOnTheNet 8y ago

Didn't and doesn't stop them from using VBA, which of course is already used by malicious entities everywhere, so if they're unwilling to stop supporting that then why not let unsandboxed python work?

brudgers 8y ago

Good point. Another architectural difference between the languages is that Javascript is a [relatively] small language with a long history of working with external API's [i.e. the browser]. On the other hand, Python has extensive standard libraries that would require alignment with Excel. For example, how does csv.reader integrate? It looks like a can of "do the obvious thing" worms and a mountain of unexpected results and documentation. Mostly, I think it comes down to Python being designed as a systems language rather than a scripting language. Integrating Python would seem to mean either a weak security model or a special (subset) version of Python. Neither is really going to meet the fat part of the Bell Curve...people who just want to get things done in Excel. Applying a 'browser abstraction' to Excel is probably better than applying an 'OS abstraction'. Anyway, JS has been a part of .NET and VS since JScript. Python, not so much.

bakery2k 8y ago
> Python being designed as a systems language rather than a scripting language Interesting - I hadn't really noticed how pronounced this dichotomy within dynamic languages is. On the one hand there are small languages designed for embedding and sandboxing (e.g. JavaScript, Lua, Tcl) and on the other hand, larger, more general-purpose languages (Perl, Python, Ruby). I always assumed that a dynamic language could work well in both contexts, but in fact, most lie fundamentally on one side of the divide or the other. Only JavaScript, due to its immense popularity, has really managed (with Node.js) to expand from the first category into the second. If Python were to be embedded in Excel, it would be expanding from the second category into the first. As you mention, to do this safely it may be necessary to create a special (subset) version of the language. Matz, the creator of Ruby, is trying to take his language in this direction with mruby [1] - a "lightweight implementation of Ruby complying to (part of) the ISO standard". But, will these subset versions ever be popular? They necessarily leave the majority of the language's ecosystem behind - and knowledge of the full language will not necessarily transfer directly to the subset. Can a subset of an existing general-purpose language, even a widely-known one, compete against other languages that are specifically designed for safe embedding? More generally, is it possible for a dynamic language to work well on both sides of the divide, or must all (even brand-new) languages choose one side or the other? [1] https://github.com/mruby/mruby https://github.com/mruby/mruby
- brudgers 8y ago
  I think the more important divide between language communities may be between consensus and individual authority. Python's BDFL and Javascript's standardization lie at opposite ends of the spectrum. To caricaturize: Javascript is the intersection of what many interested parties can agree on. Python is the union of anything that struck a single individual's fancy over the course of decades. The rise and fall of functional programming as Pythonic is a case study of the language community's arbitrariness (if Python2 v Python3 wasn't enough). As an aside, Ruby avoids this because it's vision is not tribal. Principle of least surprise allows for differences among programmers. Pythonic/unPythonic doesn't.