Live data from Hacker News

My thoughts on Python in Excel

xlwings.org

31–40 of 123 posts

Re: My thoughts on Python in Excel

#31

Earlier quoted context omitted.

Python in excel is a feature I would only expect to be used by power users. Someone who spends a lot of time in excel. Calling these people “non-programmers” isn’t true, excel itself is a pretty esoteric programming language. I personally don’t think python is the problem here, but if their users can learn python they can certainly learn lua.

They could, but a lot more people already know Python than Lua.

Most Excel users (not the power users, just the 1.1 billion everyday ones, including many of the enterprise ones) don't know how to program in any language. You're coming at this with a HN mindset.

"Python vs Lua" is not even on their radar. And even if it was, their criteria would be dominated by platform lockin and compatibility with other licenses (e.g. commercial SQL, Tableau, MSFT, etc.). Not by "which open-source language?"

Re: My thoughts on Python in Excel

#32
post #11

The big problem is that this is exactly backwards. I rarely want to access Python from my Excel. I quite often want to access Excel from my Python. A spreadsheet is a great GUI for a lot of things. A lot of people are employed creating "shitty version of Excel but can be driven from any of " Being able to easily drive Excel from an external Python program would make for a nice cross-platform application substrate.

You can access the VBA object model from Python once you've got a COM conduit. There are a few Python libraries to allow you to do this; you'll be able to write VBA-like code in Python accessing Excel's internals in a similar manner. Debugging can be a bit painful though. I've done this both from Matlab and from Python, and it's fine for smaller projects, writing structured/formatted Excel workbooks, etc.

I agree that Excel as a GUI can be phenomenal.

Re: My thoughts on Python in Excel

#33
post #2

Without interacting with it myself, none of this is surprising. I have used excel in the past, and I am a long term python user. But if you asked me today what I really wanted to make my life easier and ultimately a product or business better using only excel? I would ask for lua or scheme. I don’t need a batteries included environment embedded into a spreadsheet. I just want sane syntax for common functionality whic…

>excel is too bleh >python is too blah >myLanguageOfChoice is just right.

We can't all be special snowflakes, python and excel are lingua francas.

Re: My thoughts on Python in Excel

#34
post #33
post #2

Without interacting with it myself, none of this is surprising. I have used excel in the past, and I am a long term python user. But if you asked me today what I really wanted to make my life easier and ultimately a product or business better using only excel? I would ask for lua or scheme. I don’t need a batteries included environment embedded into a spreadsheet. I just want sane syntax for common functionality whic…

>excel is too bleh >python is too blah >myLanguageOfChoice is just right. We can't all be special snowflakes, python and excel are lingua francas.

+1. I’ve had to fire guys like the OP. Smart guys often, but nearly impossible to work with productively.

Re: My thoughts on Python in Excel

#36
post #11

The big problem is that this is exactly backwards. I rarely want to access Python from my Excel. I quite often want to access Excel from my Python. A spreadsheet is a great GUI for a lot of things. A lot of people are employed creating "shitty version of Excel but can be driven from any of " Being able to easily drive Excel from an external Python program would make for a nice cross-platform application substrate.

Fascinating to think of Excel growing into a modern replacement for Visual Basic. The spreadsheet that becomes so important to the company it’s handed over to the software developers to make it into a real application is almost a meme at this point. Being able to steadily enhance a spreadsheet into a real application without rewriting from scratch could be a real game changer.

visual basic has been included in excel for decades, its just called VBA not VB. if you thanos snapped VBA out of existence the world would probably stop functioning for several weeks.

Re: My thoughts on Python in Excel

#37
post #23

Earlier quoted context omitted.

Python in excel is a feature I would only expect to be used by power users. Someone who spends a lot of time in excel. Calling these people “non-programmers” isn’t true, excel itself is a pretty esoteric programming language. I personally don’t think python is the problem here, but if their users can learn python they can certainly learn lua.

That's exactly what I said above: most Excel users are non-programmers. Hence Python in Excel would only be used by a subset of Excel power users. Moreover, having to pay $$ recurring subscriptions for that stack to run open-source software (Python) they could run for free elsewhere mean it'll only be used by commercial/enterprise Windows-stack users who are already locked into some legacy workflow/data built around/…

Are we? I’m arguing that lua would have been a better choice than python.

Any traditional programming language that you put in excel is going to be a feature mostly for power users, and I think they could pick up lua just as easy as python

Re: My thoughts on Python in Excel

#38
We built our spreadsheet (https://rowzero.io) from the ground up to integrate natively with Python. Bolting it on like Microsoft did, or as an add in like xlwings, just feels second class. To make it first class, we had to solve three hard problems:

1. Sandboxing and dependencies. Python is extremely unsafe to share, so you need to sandbox execution. There's also the environment/package management problem (does the user you're sharing your workbook with have the same version of pandas as you?). We run workbooks in the cloud to solve both of these.

2. The type system. You need a way to natively interop between Excel's type system and Python's much richer type system. The problem with Excel is there are only two types - numbers and strings. Even dates are just numbers in Excel. Python has rich types like pandas Dataframes, lists, and dictionaries, which Excel can't represent natively. We solved this in a similar way to how Typescript evolved Javascript. We support the Excel formula language and all of its types and also added support for lists, dictionaries, structs, and dataframes.

3. Performance. Our goal was to build a spreadsheet 1000x faster than Excel. Early on we used Python as our formula language but were constantly fighting the GIL and slow interpreter performance. Instead we implemented the spreadsheet engine in Rust as a columnar engine and seamlessly marshal Python types to the spreadsheet type system and back.

It's the hardest systems problem our team's ever worked on. Previously we wrote the S3 file system, so it's not like this was our first rodeo. There's just a ton of details you need to get right to make it feel seamless.

You can try it free here: https://rowzero.io/new?feature=code

Re: My thoughts on Python in Excel

#39
post #11

The big problem is that this is exactly backwards. I rarely want to access Python from my Excel. I quite often want to access Excel from my Python. A spreadsheet is a great GUI for a lot of things. A lot of people are employed creating "shitty version of Excel but can be driven from any of " Being able to easily drive Excel from an external Python program would make for a nice cross-platform application substrate.

Since it was announced, my assumption has been that microsoft is putting python in excel like this to make using python to manipulate spreadsheets less common since that'd eat a lot of their moat around their program. If it were common enough, it wouldn't matter too much what spreadsheet program you were using.
Post reply on HN