Python Is Now in Excel — What This Means If You Don't Code
Microsoft added Python directly into Excel Copilot in April 2026, and expanded it in June and July. It's genuinely powerful. It also requires knowing Python. Here's what the update actually does, who it helps, and what the low-friction path looks like for everyone else.
In April 2026, Microsoft shipped Python directly into Excel via Copilot. In June and July they expanded it — 30+ file types, 50MB files, Power BI grounding, support for frontier AI models. The Excel newsletter said it was the biggest update in years. They're right. It also requires knowing Python. Here is what's actually changed and what it means if you don't.
What Python in Excel actually does
You type =PY( in a cell and write Python code. That code can use pandas to transform a table, matplotlib to produce a chart, or scikit-learn to run a regression — all inside Excel, without a separate environment. The result comes back into the spreadsheet as a value, chart, or spilled table.
For data analysts who already know Python, this is genuinely excellent. You get the spreadsheet's ease of distribution and the power of Python's data stack in one place. For users who don't know Python, it's irrelevant — the feature has nothing to offer until you learn the language.
Who it's actually for
Python in Excel targets data analysts, scientists, and developers who already work in Python and want to stay in the Excel environment where their colleagues live. It's a serious tool for serious technical users. It's not a simplified interface — you write real pandas code, handle real exceptions, and debug real import errors.
If you've been using Excel for years and are comfortable with VLOOKUP, pivot tables, and SUMIFS but have never written Python, Python in Excel is not for you yet. It adds a language requirement on top of everything you already know.
What about Copilot?
Excel Copilot (separate from Python) can generate formulas from plain English descriptions and assist with data analysis. As of June 2026 it can also generate Python code, which means you can ask Copilot to write the Python for you. That reduces the barrier — but you still need to understand what the code does, review it, and fix it when it generates something wrong. It's a shortcut for people learning Python, not a replacement for knowing it.
Three things nobody mentions until you try it
The coverage of this feature is uniformly enthusiastic and uniformly vague about what using it is like. Three specifics that change the decision:
- It does not run on your machine.
=PY()sends your data to the Microsoft Cloud, executes there, and returns the result. For most businesses that is fine and no different from the rest of Microsoft 365. If you handle data that is not allowed to leave your infrastructure, it is disqualifying, and it is worth knowing before you build a workflow on it rather than after. - The output is a Python object by default. Your first
=PY()cell will showPythonObjectrather than a number, and the fix is a per-cell setting switching the output from Python Object to Excel Value. This is the single most common first-hour confusion and it is not a bug. - Recalculation is sequential, top to bottom. Python cells run in row-major order, not in Excel's dependency order, so a Python cell that depends on one below it does not work the way the equivalent formula would. It is a different execution model wearing a spreadsheet's clothes.
Which of the three to use
These are not competing products; they are three answers to three different questions. Ranked by who should pick which:
- If you already write Python: use Python in Excel. Nothing else here is better at what it does. Regression, clustering, a proper seaborn chart, a transformation that would be forty nested formulas — that is its territory and it owns it. A query layer is not a substitute and I would not pretend otherwise.
- If you want to learn: use Copilot to generate the Python. It is a genuinely good on-ramp, provided you treat the output as a draft to understand rather than an answer to paste.
- If you want the answer and not the method: use a query layer. The question "which customer brought in the most revenue last quarter" has one right answer and no interesting implementation. Generating code to compute it is work you are doing for the tool rather than the tool doing work for you.
The mistake is choosing on capability. Python is the most capable of the three by a distance, and that is irrelevant if the thing you needed was a number before a meeting.
The cost of being wrong, which is the same for all three
Generated code fails in a specific and unhelpful way. It rarely throws an error. It runs, returns a plausible number, and the mistake sits one layer down: a join that matched 80% of rows, a filter comparing a date to a string, a group-by on a column with two spellings of the same category.
The direction is consistent. Silent join and filter failures drop rows, so the number comes back lower than the truth — and a slightly low figure is the hardest kind to catch, because nothing about it looks wrong.
What makes it survive review is that the code is readable and correct-looking. Reviewing df.merge(orders, on='customer_id') tells you nothing about whether the ids matched. The only check that works is the one nobody enjoys: does the total agree with a figure computed a completely different way? That question applies equally to Python, to Copilot, and to us.
Python was already available to everyone who wanted it. That is the part of this announcement I keep coming back to.
Anyone who wanted pandas could have had it for a decade, free, one download away, with better tooling than a spreadsheet cell provides. Putting it inside Excel removes a genuine friction and I do not want to be sour about a good piece of engineering. But leading business intelligence for large enterprises taught me that the constraint on getting answers out of data was almost never expressive power. It was agreement.
The meetings I sat in did not stall because nobody could compute the number. They stalled because two people had computed it and got different answers, and the next hour went on whose definition of an active customer was right. No amount of capability in the cell touches that. It arguably makes it worse, because a more powerful tool produces more variants of the number faster.
So when a tool of any kind lands, the question I have learned to ask is not what it can now compute. It is whether it makes the definitions easier to agree on and harder to diverge from. Python in Excel does not claim to, and it should not be criticised for that — it is a computation feature and an excellent one. It is worth being clear-eyed that the reporting bottleneck in most organisations is not sitting where this lands.
The no-code path
If what you actually want is: "ask a question about my spreadsheet data and get the answer" — not "generate a Python script that computes the answer" — that's a different category of tool altogether. It's a query layer, not a code generator. You upload your file, ask "which customer brought in the most revenue last quarter," and get back the number. No formula, no Python, no Copilot output to verify.
That's the path that Quiriz is built for — SMB owners and analysts who live in spreadsheets but don't want to write code every time they have a new question. The Excel add-in (Microsoft AppSource) and Google Sheets add-on do this inside the spreadsheet itself, so you never have to leave the tool you're already in.
One correction to how this is usually pitched, including by us. The alternative to reviewing generated code is not an answer that needs no checking — we argue the opposite in why AI gives different numbers, and it would be inconsistent to drop the argument here because it is inconvenient. The alternative is an answer whose definition is fixed and inspectable, so that what you are checking is a stated rule rather than someone's code. That is a smaller thing to verify and it stays verified between questions. It is not nothing to verify.
The honest limit, then: if your question genuinely needs a regression, a clustering, or a transformation with real logic in it, Python in Excel is the right tool and we are not it. What we replace is the large majority of questions that were never analytically interesting in the first place — totals, breakdowns, comparisons, trends — and only ever needed writing down once.
Ask your spreadsheet a question
Upload your Excel file or connect your Google Sheet, ask in plain English, and get the answer in seconds. No Python required. Free to start.
Try Quiriz free →