If you've ever dealt with AWS Lambda you will know what a versioning and upgrading shit show this is going to be wherever you stick it, be that client or cloud.

I worked on a very early python integration used as a workflow DSL back in 1998 and they had to dump it and write their own DSL in the end.

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 compatibility, though

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?

Computers are computers. Potentially new Excel would be incompatible with old cloud Python environments. Potentially new Excel would be compatible with old local Python environments.

Isn't that already an issue? I've definitely needed specific versions of excel to open particular workbooks before.

Excel already has versioned file formats with significantly different affordances, and hasn't appeared to have all sorts of compatibility headaches as a result.

Integrating a whole separate language ecosystem is one or two orders of magnitude more complex though. It’s more like HTML5/WHATWG suddenly adding Python as a first-class scripting language besides JavaScript, and web browsers having to integrate that.

Isn't this what people are trying to do with pyscript? Although in that case it uses WASM?

It’s different because WASM is much more strictly defined and has a more limited scope than Python. Thanks to WASM, browsers don’t have be able to understand Python/PyScript. The trade-off is that you can’t, for example, view/edit the Python code in the browser’s devtools.

A WASM-like approach wouldn’t work very well for Excel, because you’re supposed to be able to edit the source code/formulas within the Excel application.

> It sort of makes sense to limit it to the cloud, because making Python an integral part of the Excel file format

Moving it from the cloud to local doesn't make it an integral part of the Excel file format. Whatever python service is running in the cloud could just run locally.