Home / Blog / Python in Excel
How-to · 2026

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.

By · Published July 31, 2026 · Updated August 18, 2026 · 8 min read

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:

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:

  1. 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.
  2. 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.
  3. 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.

From twenty-five years of this

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.

The update in context: Python in Excel (April 2026), Copilot + 30 file types (June 2026), Power BI grounding + Claude Opus 5 support (July 2026). These are real, substantial improvements to Excel for technical users, and the common thread is that each assumes you are comfortable reviewing AI or code output.

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 →

Frequently asked questions

What is Python in Excel?
Python in Excel is a feature in Microsoft 365 that lets you write Python code inside a cell using the =PY() function. The code runs against your spreadsheet data and returns a result — a chart, a statistical output, a transformed table — back into the sheet. It uses the same Python libraries data scientists use: pandas, matplotlib, seaborn, scikit-learn.
Do I need to know Python to use Python in Excel?
Yes. Python in Excel requires writing actual Python code. You need to understand Python syntax, how pandas DataFrames work, and which functions to call. It's a genuinely useful feature for people who already know Python — not a no-code tool.
How is Python in Excel different from Copilot in Excel?
Copilot in Excel generates formulas and provides suggestions in plain English, but it still requires you to understand and verify the output. Python in Excel lets you run arbitrary Python code directly — more powerful, more complex. As of June 2026, Copilot can also generate and run Python code, which blurs the line. The common thread is that both require some technical review.
What can I use instead of Python if I don't code?
If you want answers from your spreadsheet data without writing formulas or code, the alternatives are tools that take your question in plain English and return the answer. That's a different category from Copilot or Python — it's a query layer, not a spreadsheet assistant.
Does Python in Excel run on my computer or in the cloud?
In the cloud. The code executes on Microsoft servers and the result is returned to the sheet, which means your data leaves your machine to be processed. For most businesses this is no different from the rest of Microsoft 365 and is not a concern. If you work under data-residency rules that prevent spreadsheet contents leaving your own infrastructure, it rules the feature out — and that is worth establishing before building a workflow on it.
Why does my Python cell show PythonObject instead of a number?
Because that is the default output mode. Each Python cell can return either a Python object or an Excel value, and it starts on the former. Switch the cell output to Excel Value and the result appears as a normal number, text or spilled array you can reference from other formulas. It is the most common first-hour confusion with the feature and it is not an error.
Is Python in Excel worth learning if I only need totals and breakdowns?
No. Python earns its keep on work that formulas genuinely cannot do — statistics, modelling, complex reshaping. Totals, group-bys and period comparisons are not that, and learning a language to produce them is a large investment for a class of question that was already solved. Learn Python because you want the analytical range, not because you want next month's numbers faster.