Live data from Hacker News

My thoughts on Python in Excel

xlwings.org

91–100 of 123 posts

Re: My thoughts on Python in Excel

#92

I was quite excited when I heard Python was coming to Excel but the execution pretty much guarantees that adoption is going to be horrible. If I as MSFT wanted to get people to write Python scripts that can take advantage of Excel's great abilities this is probably the worst way I could have gone about it. A ham-fisted, cloud-first feature implementation that is basically jammed into the product without appropriate c…

"Cynically, I would say that they've messed up the implementation on purpose so they can put a bullet through the "Python in Excel" idea without actually doing anything useful."

Sounds exactly right. Embrace/extinguish. It's The Way.

Re: My thoughts on Python in Excel

#93

Earlier quoted context omitted.

As the author of said second class add-in, let me just guess that your most popular feature request was adding the "Import from xlsx" functionality...which describes the whole issue: it's always Excel + something, never something instead of Excel.

My apologies, that came off harsher than I intended. I've used xlwings in previous jobs to complete Excel automation tasks, so thank you for building it. xlwings is one of the projects that motivated me to start Row Zero. My main issue with it, and other Excel add-ins, is they break the promise of an .xlsx file as a self-contained virtual machine of code and data. I can no longer just send the .xlsx file - I need the…

No offense taken, and happy that xlwings was an inspiration for creating Row Zero! I don't really buy the security issues though for being the reason for switching from Excel to Row Zero. Yes, Excel has security issues, but so does the cloud, but at least the issues with Excel can be dealt with: disable VBA macros on a company level, run Excel on airgapped computers, etc. Promising that your cloud won't be hacked or is unintentionally leaking information is impossible, no matter how much auditing and certification you're going through. The relatively recent addition of xlwings Server fixes pretty much all of the issues you encountered in your previous company: user don't need a local installation of Python, but the Office admin just pushes an Office.js add-in to them and their done. No sensitive credentials etc. are required to be stored on the end-users computer or spreadsheet either as you can take advantage of SSO and can manage user roles on Microsoft Entra ID (that companies are using already anyways).

Re: My thoughts on Python in Excel

#94
post #80

Earlier quoted context omitted.

Excel implementers struggle with it. Half the features of Excel cannot deal with named cells. Try for example to use named cells in Conditional Formatting. Doesn't work at all, ranges cannot be named cells or tables, and condition formulas can only reference named cells with extremely ugly contortions. There are lots and lots of additional examples of similar problems. Excel is a loose agglomeration of unrelated feat…

I've always wondered why they've never done a basic pass of fixing stuff like this.

Worked with the Excel team on the 2007 beta. They want to do this too, but program managers give them a hard "No." If you touch even one thing there is a cascade of side effects that will drag you off the local maximum.

The PMs are right. It would be expensive to do this and it would piss off existing customers.

Re: My thoughts on Python in Excel

#96

Earlier quoted context omitted.

Did you try the ScriptForge library shipped with LibreOffice: https://help.libreoffice.org/latest/en-US/text/sbasic/shared... See the SFDocuments.Calc service there. ScriptForge makes it more convenient to work with the API. Using it with Python: https://help.libreoffice.org/latest/en-US/text/sbasic/shared...

I hadn't come across the ScriptForge library before so I just looked it up. It looks pretty cool and definitely looks like how MSFT should have worked on including Python in Excel. From my quick look, it looks like ScriptForge is primarily a BASIC which supports Python(?). So I can only imagine how much more powerful a Python specific library could be given the differences in Python and BASIC themselves.

No need to use BASIC, you can use ScriptForge in LibreOffice Python macros directly. ScriptForge is also available for use with LibreOffice BASIC macros.

Re: My thoughts on Python in Excel

#97
As a counterpoint to a lot of the speculation on this thread, if you're interested in learning more about how and why we designed Python in Excel, I wrote up a doc (that is quite old but captures the core design quite well) here [1]. Disclosure: I was a founding member of the design team for the feature.

[1] https://notes.iunknown.com/python-in-excel/Book+of+Python+in...

Re: My thoughts on Python in Excel

#98
post #64

Earlier quoted context omitted.

> Make a special library that can be called from the language and which only works with Excel There are plenty of those libraries without the "only works with Excel" part, if you mean to have Excel running on the machine. As a Python example, a customer of mine is using XlsxWriter and openpyxl for .xlsx files, xlrd for .xls plus python-docx for dealing with docx files. I don't remember why the two modules for xlsx fi…

> What I expected was a VBA editor for Python and maybe a library for Windows to access Excel objects from a Python script in a cmd or powershell prompt. This is exactly it. The killer feature for including any modern scripting language in Excel. Both XlxsWriter and openpyxl can r/w from Excel files but I have to manipulate the data using another library like `pandas`. Instead if MSFT gave a library which I can impor…

You can do this through COM. I forgot which Python library I used but once you have an Excel application object you can do

Data = xl.range('a1:a3')

Sum = xl.worksheetfunction.sum(data)

Xl.range('b3').value = sum

Any library enabling the COM link will do.

(sorry, typing this on my phone so formatting and capitalization are screwy)

Re: My thoughts on Python in Excel

#99

As a counterpoint to a lot of the speculation on this thread, if you're interested in learning more about how and why we designed Python in Excel, I wrote up a doc (that is quite old but captures the core design quite well) here [1]. Disclosure: I was a founding member of the design team for the feature. [1] https://notes.iunknown.com/python-in-excel/Book+of+Python+in...

I'm genuinely curious why python instead of something like PowerShell for Excel specifically. Seems a little out of the farm but I also get how it's a more adopted language.

Re: My thoughts on Python in Excel

#100
post #77

Maybe its time to start fresh with a clean sheet? (Pun). The spreadsheet paradigm is immensely intuitive and arguably the only alternative to the standard procedural programming currently in use in number crumching. But therein lies also a major weakness when used for important tasks: hard to validate. Once you further combine it with API calls and whatnot, the situation gets totally out of hand: how do you reproduce…

I tried that exactly with PySheets by implementing the sheet in Python itself, rethinking how Jupyter Notebook would look if it treated the data science problem as a dependency graph rather than a linear storytelling document. See https://pysheets.app

https://news.ycombinator.com/item?id=40179566 - PySheets – Spreadsheet UI for Python (pysheets.app) - 287 points - 47 days ago - 74 comments
Post reply on HN