Back in 2005, some friends and I started a company called Resolver Systems to build a Python-enabled spreadsheet, which we called Resolver One. Sadly, it never took off in the marketplace, and we had to pivot; we would up creating PythonAnywhere, an online coding and hosting environment, which worked out pretty well and was acquired by Anaconda last year. And now, the circle is closed :-) (Just for clarity: the team…
It was a great product - I remember your pitch and indeed we met a few times at the London python for finance meetup (remember the "Enthought Python Distribution"?). The only issue is that Resolver was IronPython-based so there were a bunch of libs that kinda didn't work.
Thanks for your work! The async JS functions are amazing and allowed me to ship rock-solid Custom functions with xlwings and Python. The problem with Office.js is that it’s just simply too hard to get started with all the npm bloat for the average Excel user (even more professional devs struggle). Well, I am pretty happy how I am saving users from having to use Node.js: https://docs.xlwings.org/en/latest/pro/server/o…
Oh this must be Felix! I saw and played with xlwings many years ago and was impressed :) Agreed with the friction around getting started. I would like to see it reduced. It’s cool to see you using them to wrap Python functions - I have done something similar before myself, and still need to get around to shimming Haskell into excel at some point. Another thing I don’t like is how JavaScript Custom Function cell formu…
It's me, yes, are you Michael then ;)? Yeah, I love the Office.js platform, I believe it's the most versatile extension platform there is, it just came out during an unfortunate time (when people believed that you can't use JS without React anymore ;) Anyhow, the magic of Office.js is that you can use it like a JS framework with total freedom what you use on the backend (it's just a fetch call away), so whether that is .NET or Node or Python/R/Julia doesn't matter at all, it's just that the official docs don't really bother to explain that or show an example other than Node & C#. What's a game changer (and only available on Office.js) is the integrated authentication via SSO/Azure AD, which is the first thing any IT department in a corporation is interested in.
> games have been skipping with Python scripting for decades That only works if there is a forever fixed version of Python embedded in your game. The value of Python in this context is its ecosystem and folks will need to install additional packages and libraries into the execution environment. Now you're managing a local distribution of Python.
Yeah, but if the big value is supposed to be in the libraries you sort of have to accept dependency hell? Otherwise you're in the world where a small set of libraries can deliver all the functionality ever needed. Of the currently available solutions, "cloud environment made by Microsoft" doesn't sound that different from "software update made by Microsoft" in terms of how it solves the dependency hell: basically, th…
Dependency hell may be an issue if you install arbitrary libraries into the container at runtime. Note that this feature isn't currently available in the preview.
On versioning: we freeze the container image that your Workbook was authored against. You need to manually accept (and validate things continue to work) updates to that container image as we roll forward.
It’s interesting but if you are good enough at Python, can’t you already write to and read from spreadsheets? Maybe moving up a Python excel library like xlrd and openpyxl and making it reactive would be more worthwhile for Microsoft. Writing Python code in that little formula bar as shown doesn’t seem attractive. Writing Python in VSCode and seeing the results appear in the spreadsheet in real time would be great th…
No, you use Excel when you need a data manipulation program quickly and you want to ship it to clients without any installation or training. You just send the workbook to your client and it's done! It's very self-contained, what works on your machine is almost guaranteed to work on the client's computer, given that they have the same Excel version. It's also very reliable, VBA apps can work for years without any main…
Great points, since it’s in the cloud it’s no longer self contained. We are already in some hybrid works with extra dependencies.
And if that’s the case, why can’t the .py files live in the cloud too? The need for an interpreter didn’t go away, Microsoft is just hosting it for you.
It sort of makes sense to limit it to the cloud, because making Python an integral part of the Excel file format would reduce its portability and introduce all sorts of compatibility headaches going forward.
Whether it runs in the cloud or locally, the included python source will be written for a specific runtime version and environment. If excel were to run python locally, it would presumably bundle an interpreter (+ any needed pip packages) rather than relying on whatever was installed locally. The cloud execution model does still have an advantage in that it can retain old runtimes in perpetuity for backwards compatib…
Making software available for download perpetually is less complex than making software available for cloud execution perpetually.
Not OP but I would never want to use this if I was running a security minded business. Why would it be okay to send out my entire dataset to the Microsoft cloud to run a few simple queries. How long is the data stored on your servers? Since it’s operating on the data directly, it’s not possible to anonymize or redact the contents of the data.
Practically speaking, if you are running recent versions of Windows (I don't remember when exactly this trend started, with 2000? XP?), you have basically no control over what data you send to them and when. You can try to block traffic but it will interfere with normal Windows operations. You can try to investigate and play cat and mouse game with Microsoft, but they will always be one step ahead of you - unless you…
I’d wager that most of that data is anonymized and redacted usage and error stats. Big difference between that and entire data sets
> This alone could eliminate the need for websites that just want this sort of data I catch flak for this all the time! Our users just want to be able to use Excel to free-form analyze their data. IT, of which I'm a part of, insists on building web apps to do that for them. They're never happy because all they wanted was Excel. I keep explaining all we have to do is build a data mart built using SQL Server, and use o…
Google’s ecosystem makes this incredibly simple.. all you need is to populate BigQuery with the datasets of interest, and Sheets can pull it in via a connector that’s configureable in a GUI. I sincerely hope my org never migrates to MS for this reason alone.
Came here to say the same thing.
Another good reason to not migrate to MS is that they are a security disaster.
Whether it runs in the cloud or locally, the included python source will be written for a specific runtime version and environment. If excel were to run python locally, it would presumably bundle an interpreter (+ any needed pip packages) rather than relying on whatever was installed locally. The cloud execution model does still have an advantage in that it can retain old runtimes in perpetuity for backwards compatib…
Making software available for download perpetually is less complex than making software available for cloud execution perpetually.
Under the model you're proposing, would I potentially need to download an old copy of Excel because the sheet I'm trying to load relies on an older python runtime?