Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft is bringing Python to Excel

theverge.com

Post reply on HN
Print view View original

381–390 of 455 posts

Re: Microsoft is bringing Python to Excel

#381

Post by cfiggers »

plaidfuji wrote: post #246
taylodl wrote: post #57

Earlier quoted context omitted.

> 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.

Google's Data Studio is pretty good as well—shame about the recent rename to "Looker Studio."

Re: Microsoft is bringing Python to Excel

#382

Post by Sylamore »

nitwit005 wrote: post #351
Sylamore wrote: post #310

Earlier quoted context omitted.

In multiple orgs now I've had raw access to data warehouses (DB2 and SQL Server based) that had aggregates of petabytes of data from ETL that I was free to access via Excel PowerQuery, direct SQL tools, Python or R, or even PowerBI.

If you're getting aggregates, it's not the raw data by definition. Someone set up aggregation for you to use, much like I described.

I didn't mean aggregate as in summarized data, but aggregate as in a common repository of multiple different data sources as a single massive data warehouse. If I needed to group or summarize the data, I had to do it in my own queries.

Re: Microsoft is bringing Python to Excel

#384

Post by pphysch »

mulmen wrote: post #302
pphysch wrote: post #215

Earlier quoted context omitted.

> I keep explaining all we have to do is build a data mart built using SQL Server, and use our ETL tools to keep it populated with the data they need to analyze. I mean, that's like >90% of building a CRUD web app. If you truly only need the R in CRUD, your approach sounds reasonable. Otherwise, just go the extra distance and build a CRUD app with csv export / direct SQL access.

I’m physically uncomfortable with the idea of a CRUD app for a data mart.

Why?

Re: Microsoft is bringing Python to Excel

#385

Post by tap-snap-or-nap »

xorcist wrote: post #193
nologic01 wrote: post #35

I wish Libreoffice would have smelled the coffee long time ago. In principle scripting using Python is possible but exceedingly cumbersome/ugly and there seems to be no roadmap to improve on this. The same warning applies to the linux desktop and all its apps more generally. Increasingly proprietary platforms will be rolling out advanced "AI" functionality extensions to classic apps that are cloud based, many of them…

Umm... Libreoffice has shipped with Python scripting since almost forever. Not many people care because the most popular use case of any office suite is to interoperate with Microsoft file formats.

To be honest, I don't even fully understand what are the use-cases for integrating python with spreadsheets right now. I use both of them separately for different things but cannot see what it can be good at doing in an integrated environment.

Re: Microsoft is bringing Python to Excel

#386

Post by mulmen »

pphysch wrote: post #384
mulmen wrote: post #302

Earlier quoted context omitted.

I’m physically uncomfortable with the idea of a CRUD app for a data mart.

Why?

Because then you can’t trust it. The only changes to a data mart should be replicated from authoritative upstream systems.

Re: Microsoft is bringing Python to Excel

#387

Post by navbaker »

bigger_cheese wrote: post #378
taylodl wrote: post #57

Earlier quoted context omitted.

> 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…

How do you lock down Excel - that is the issue we have where I work and the main reason excel is strongly discouraged. There are two main issues my org has battled with: 1.People basically turn excel into their own mini databases which causes a support nightmare. 2. This is strongly related to 1) Data provenance is a nightmare because so many people were passing around excel spreadsheets it became very difficult to t…

3rd_quarter_draft_final_krf_v3_edits.xslx

Re: Microsoft is bringing Python to Excel

#388

Post by SonicScrub »

rehitman wrote: post #380
adfgionio wrote: post #379

Earlier quoted context omitted.

>Probably because most users of excel don't have any experience installing and running Python which is even a pain in the ass for people that know Python lol. An embedded Python is about 10 MiB. I just checked. Excel could easily have its own separate copy.

But don't you need to install lot of packages for it to be useful?

Based on the announcement it looks like the standard data-science libraries (numpy, pandas, matplotlib, seaborne) will be available. The covers a lot of use cases. However I would really appreciate the ability to set the python interpreter to whatever I want. Then I could access the niche libraries I need (shout-out to JSBSim for open source flight dynamic modelling). Or even better, hooking up my organizations custom libraries we built for our own specific data analysis applications. Huge value add. Shame this likely won't be possible. Unless I've misunderstood some part of this.

Re: Microsoft is bringing Python to Excel

#389

Post by pphysch »

mulmen wrote: post #386
pphysch wrote: post #384

Earlier quoted context omitted.

Why?

Because then you can’t trust it. The only changes to a data mart should be replicated from authoritative upstream systems.

That is quite a generalization, not every data warehouse / mart / workflow is architected in the exact same way.

Re: Microsoft is bringing Python to Excel

#390

Post by ripley12 »

fzumstein wrote: post #337
ripley12 wrote: post #324

Earlier quoted context omitted.

> 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) IMO deployment is an even harder problem. The Office team makes it incredibly difficult to deploy web add-ins (presumably for business reasons) and accordingly most companies I'm familiar with are still using the ancient, barely-supported COM+VSTO add-i…

Which part do you find difficult? The web backend or the deployment of the Manifest.xml via the app store / office admin?

The app store / Office admin stuff. When I was dealing with this stuff 2 years ago, it was insanely difficult to deploy a web add-in internally (something involving the "Microsoft 365 admin center"), let alone deploy it to customers (gotta get approval to deploy it in the special Office app store, and hope+pray that your customers' IT departments don't block that).

Compare to VSTO, where IIRC installation just involves editing a registry value to let Office know where your add-in can be found on disk.

Post reply on HN