My thoughts on Python in Excel
Microsoft’s new “Python in Excel” feature is drawing mixed reactions from developers and power users, who argue it solves the wrong problem and is awkwardly bolted onto the grid as an alternative to formulas rather than a true replacement for VBA-style scripting. Many criticize its cloud-only execution, weak integration with Excel’s native object model and types, and the resulting lock-in and reliability concerns, while others note that Python’s data science ecosystem and mindshare still make it an attractive direction if implemented with better local support and tooling. Several commenters highlight competing approaches—from xlwings-style automation to new Python-native spreadsheet engines—as more coherent ways to combine spreadsheets with modern programming.
Who Python in Excel Targets
- Many see the feature as aimed at Excel “power users” (analysts, quants) rather than the ~billion casual users.
- Debate whether these users are “non‑programmers”: some argue heavy Excel use is already a form of programming.
- Enterprise/Windows lock‑in and subscription pricing are seen as strong filters; widespread grassroots adoption is viewed as unlikely in the short term.
Debate Over Language Choice
- Some argue Lua or Scheme would be better embedded languages: simpler, designed for embedding, fewer “batteries” needed.
- Others counter that Python has massive mindshare, rich numeric/data ecosystems, and existing presence in finance and analytics; Lua/Scheme would have almost no pull in those environments.
- For most Excel users, the “Python vs Lua” question is viewed as irrelevant; they don’t program at all.
Critiques of Microsoft’s Implementation
- Seen as an alternative to the formula language, not to VBA; disappointment from those wanting a modern scripting replacement.
- Integration of Jupyter‑style cells directly into the grid is widely criticized as awkward and confusing.
- Execution order (left‑to‑right, top‑to‑bottom across sheets) evokes memories of brittle old macro sheets.
- Poor naming/ranging ergonomics, messy interaction with existing features (LET, LAMBDA, named cells), and hard version control are recurring complaints.
- Some suspect it’s intentionally half‑baked so the idea can be killed later.
Cloud vs Local Execution and Security
- Cloud‑only Python is heavily criticized: dependency on connectivity, Azure outages, and regulatory/privacy (e.g., GDPR) concerns.
- Others note cloud execution helps sandbox Python and standardize environments and packages.
- Counter‑argument: Excel’s security issues can be mitigated locally (macro policies, airgapping), while no cloud can credibly promise zero leakage.
Alternative Approaches and Tools
- Many prefer “Excel as presentation layer, Python/R outside”: extract data (SAP, DBs), process with scripts, re‑import to Excel.
- Existing tools: xlwings (drive a live Excel instance from Python), COM automation, openpyxl/xlsxwriter, LibreOffice + Python/ScriptForge, Power Query/M.
- New products rethink the model: spreadsheets natively integrated with Python and richer type systems (e.g., dataframes, lists, dicts) and Rust backends; or Python‑centric spreadsheet UIs (PySheets, IronCalc, others).
Rethinking the Spreadsheet Paradigm
- Several argue the real problem is the grid itself: hard to validate, version, and reproduce once APIs and logic accumulate.
- Proposals include dataframe‑like tables, ORM‑style operations, multidimensional modeling (as in enterprise tools), richer formula languages, and better tracing/debug features.