Live data from Hacker News

My thoughts on Python in Excel

xlwings.org

81–90 of 123 posts

Re: My thoughts on Python in Excel

#81
post #42
post #10

I agree with xlwings about this but for different reasons. MS are a company wot makes money. Python was added to Excel cos R and Python and so on - market share. I suggest you do what my brother does and unanswer the question! He works for quite a large firm and is surrounded by quite a lot of data. He is a Windows user by routine and asked me for some help. I got Python + MS Visual Code installed and integrated for…

That workflow sounds so painful. Why not get a BI tool that can integrate directly into your data warehouse and do reporting through that?

It's really not, I've used python in the past but prefer R for this.

As it stands excel is a better presentation layer than almost all BI tools once you're past the modelling and analysis stages.

Re: My thoughts on Python in Excel

#82
post #63

> We wanted an alternative to VBA, but got an alternative to the Excel formula language. indeed > Integrating the Jupyter notebook cells inside the Excel grid was a mistake. 100% agreed. this seems like the typical Microsoft behavior where the team A was pushing their product and won over team B, even though it's not really what users needed > Python in Excel isn’t suitable for Python beginners nor for interactive da…

You can do multiline formulas in the advanced formula environment, but still follows the same syntax as the formula language (with comments). i.e.: =LET( x,1, // assign 1 to y y,2, // assign 2 to y x+y // add x and y ) Same with LAMBDAs

You can use Alt+Enter to create multiline formulas in normal formula entry. In addition, the formula bar can be dragged down (or press Ctrl+Shift+U) to be multiline [0]. One drawback is that you can’t use the Tab key for indentation and have to use spaces.

[0] https://www.ablebits.com/office-addins-blog/formula-bar-exce...

Re: My thoughts on Python in Excel

#83
post #78

The mistake is "the grid". The spreadsheet as a way to allow IT-illiterate to do stuff on a desktop is a mistake. Yes, we do need some kind of tabular data UIs but SMALL UIs elements, not the base of the UI. Beside that the obscene "wrapping" of Python to make it "user-safe" makes also it next to useless. A less ugly approach to tabular UIs is the one from R-Studio, while it's limited, another is org-mode tables whil…

> The mistake is "the grid". The spreadsheet as a way to allow IT-illiterate to do stuff on a desktop is a mistake.

But why?

Re: My thoughts on Python in Excel

#84

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…

These are exactly the issues I would have guessed you would run into when using Python in a spreadsheet. Python has really been promoted above its level of competence. It's not suitable for these things at all.

I would say Typescript is a more obvious choice, or potentially Dart. Maybe even something more obscure like Nim (though I have no experience of that).

I get that you want compatibility with Pandas, Numpy, etc. but you're going to pay for that with endless pain.

Re: My thoughts on Python in Excel

#85

I looked at the clients package and had a bit trouble understanding where it sits in the Python-excel landscape. Is it a competitor to openpyxl? The pro version has quite a price tag, so I’m assuming they have a big value add.

xlwings is a competitor to VBA rather than openpyxl: openpyxl can read and write the Excel file on disk, without involving the Excel application. xlwings is all about automating the Excel application, and write macros and custom functions in Python.

Re: My thoughts on Python in Excel

#86

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…

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.

Re: My thoughts on Python in Excel

#87

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…

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 recipient to install (e.g.) Python first. This makes collaboration a nightmare.

I wanted a spreadsheet interface, which my business partners need, but with a way for power users (me) to do more complicated stuff in Python instead of VBA.

To borrow your phrasing, our thesis is that it has to be Excel-compatible spreadsheet + something, not necessarily Excel + something. It's early days for us, but we've seen a couple publicly traded companies switch off Excel to Row Zero to eliminate the security risks that come with Excel's desktop model.

Re: My thoughts on Python in Excel

#88
post #78

The mistake is "the grid". The spreadsheet as a way to allow IT-illiterate to do stuff on a desktop is a mistake. Yes, we do need some kind of tabular data UIs but SMALL UIs elements, not the base of the UI. Beside that the obscene "wrapping" of Python to make it "user-safe" makes also it next to useless. A less ugly approach to tabular UIs is the one from R-Studio, while it's limited, another is org-mode tables whil…

> The mistake is "the grid". The spreadsheet as a way to allow IT-illiterate to do stuff on a desktop is a mistake. But why?

At a basic level because we almost never have to deal with pure tabular data without anything else. A spreadsheet was designed to deal with pure data, even without a note. Than since in the real world we need notes, titles, small bits of text etc spreadsheets devs add styling and the nightmare began, a grid to deal with data, but also formatting styles, people to manually tweak column and row width and height, add colors, ... all manually of course. Then overflowing text. At a certain point in time Microsoft decide to allow "integration", witch is not integration at all (OLE, with the ability in this case to insert a spreadsheet inside a text document) and the nightmare keeps extending.

The most basic error is WYSIWYG, it can work to a certain extent, like CAD systems, where you can "free draw" something but any line have defined parameters, we have snap concept to state a line is connected to another, defined properties like length and so on so in the end we have "a model", a free draw witch is also a set of data constrained/in relation with a set of functions but in general it's a nightmare. The second basic error is try to compensate the lack of integration, a system designed for commercial purpose in witch any software is a standalone closed product, by adding features that in theory can only grow to create "the complete thing" witch is an impossible goal and makes in practice just bloatware. The third basic error is consider users a bunch of imbeciles who can only learn a thing "click around on some pictogram and enter text like a chimp plunging fingers slow and hard". If you craft something simple and explain the principle behind people will learn and act. Oh, of course you need a bit of INITIAL training but after it they are ready, like teaching how to fish vs giving a fish to a hungry person. Oh, of course commercially hungry people are nice, they are tied to the vendor and they keep spending, being locked where they are, but locked people are not productive, like slaves do not work well compared to free employees.

That's the spreadsheet mistakes and modern IT mistake in general: the will to keep users ignorant while trying to made them productive anyway instead of teaching them, giving them powerful tools. It's not transforming anyone in an engineer, it's just the same concept of schooling for all, ensuring anyone have a minimum culture needed to be a Citizen in a society.

Re: My thoughts on Python in Excel

#89
post #49

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…

Looks very cool. Will be keeping an eye on this for local network hosted and/or desktop application version. Thanks for sharing!

We have private hosting available (in your VPC) for enterprise customers.

Re: My thoughts on Python in Excel

#90

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…

Seems to me that Airtable is pretty much what you’re talking about, and is spectacularly useful.
Post reply on HN