231–240 of 280 posts
Earlier quoted context omitted.
Yeah, matplotlib, scipy and numpy are kinda no-brainers there.
Please not matplotlib ... are we really stuck with matplotlib forever ..?
There are now plenty of Python modules for working with Excel and Excel format files. Why are they trying to compete with those? As a university teacher I have dropped the use of Excel from my classes. I'm really not convinced this would convince me to go back. The philosophy of the product is just wrong. The should probably consider retiring Excel itself while maintaining support for Excel file formats. If they were…
>Excel as a front-end to Python is just a bad idea I think a lot of people would like this because you can look at more data on your screen at once with excel compared to jupyter notebooks. What's the downside?
http://www.prweb.com/releases/spreadsheet/competition/prweb1...
I thought it was a good idea at the time, especially after having read "A Small Matter of Programming" which makes the case that spreadsheets are one of the very few successful end-user programming systems (the other being CAD):
Earlier quoted context omitted.
That's for the Excel team to decide. My personal hope is that they'll offer as a base: * Python 3 * Numpy, SciPy, Pandas, Matplotlib, Altair, ... * Pythonic bindings for Excel APIs (sheets, etc etc) * VSCode's Python Editor + Debugger built in * Some sort of conda based env/pkg mgmt * Right-click, "Open in Jupyter" (data/code) *
Transparent access to Excel tables as Pandas Dataframes would be so, so very awesome. I mean, MS implemented these really nice Tables in excel, but then left us no way to easily query them with something like SQL.
I hate to say it but why not ECMA Script (JS)? It’s everywhere and everyone knows enough to get by...
App Script for Google Docs/Sheets is very powerful and one of my favorite features:
https://developers.google.com/apps-script/guides/sheets
It makes for an excellent API runner. You massage a data set and then run it against an API very easily.
An absolute no-brainer. Python is the new BASIC - very popular with people who have to program to do their work but aren't programmers. It's an excellent choice for a spreadsheet.
Although, certain consumers (the financial industry comes to mind) might have so many massive, old, linked, and undocumented VBA-enabled spreadsheets that they would probably prefer VBA to at least be supported on a legacy basis for ever and ever.
You can already do this with xlrd and xlwt.
Excel spreadsheets are cool because if you update data somewhere, it'll update all the formulas and products elsewhere. How do you get that kind of "watch" behavior with `xlrd` and `xlwt`? You don't, you have to re-run a script. Sucks.
it could be entirely possible that you could create both VB modules and Python modules in alt-f11 and functions and subs from either could be called from the spreadsheet. this would be great. if python had to be run in a separate app, not so great.
will python in excel rely on the environment(s) installed independently in the system or the excel python environment? if the former, how to standardize runtime across different machines?
support for the scipy libs and matplotlib would be nice. maybe matplotlib will generate plots in its own window - 6/10 if so. if matplotlib can generate plots as its own object within excel sheets - 7/10. if the plot is reactive to changes along its dependency chain - 9/10. if you can right-click format shape and adjust colors, lines, scales, axes - 10/10
support for python exception handling - well... ANY exception handling besides "ON" ERROR GO TO" / "RESUME NEXT" - 11/10
python with alt-f11's immediate and locals window + breakpoints + steps - 10/10.
what about windows api? office interop? internally built xlls? guessing these will remain with VB and will remain compatible. guessing excel/office object models will also remain the same structure in python for excel.
don't really care about output into jupyter. excel has "cells" too so you could technically output into a protected sheet if you wanted a read only report. we used to generate publications out of excel - chuck in some data into the sheets, matlab takes over the computation and spits it back into excel and a full report with cover sheet / table of contents / page numbers etc will be generated and we'd print and bind it professionally and send it back to the client.
just a philosophical musing... excel is very "functional". from each cell/cse-array in your raw data to each cell/cse-array in final output there really ought to be a single chain of functions. i see a few comments here and on reddit where people are looking forward to happily blasting for loops on each cell in book-wide subroutines. that breaks the "functional"-like quality of excel. that makes excel a million times harder to audit. excel at its best should look a lot like f#.
Earlier quoted context omitted.
That's because you're not testing things that wouldn't require tests in a static language. You're testing things that need testing either way, and incidentally also testing the types.
No, you're testing types and verifying the implementation details of the language. It's rare that a test for logic "incidentally" tests the type system. Usually both the logic and type checks are tested. It's just obfuscated because the bulk of the test is for checking the types and it's easy to look past that.
However, it tests values for correctness. Values have types. So if you are testing whether something has the correct value, you are also testing implicitly that it has the correct type, because for the values to match, the types must also match.