The latest Power BI Desktop update slipped in something I'd been quietly hoping for: you can now run Python scripts right inside the query editor — as a data transformation step, sitting alongside Power Query M. And I'll be honest, I was excited, because I'm a Python girl at heart. So I went in wanting to love it. This is the post about what happened when I actually tried it, and why — despite genuinely liking it — I'll probably keep passing on it for real work.

The test

I diligently followed the official docs, and the first hurdle was the least interesting one: getting Power BI to talk to my Python install and libraries. I already had Python set up on my machine, but Power BI had opinions about which install and which packages it could see, and it took some fiddling. I'll chalk that down to me not paying enough attention during setup rather than anything fundamental — once it connected, it connected.

And once it worked? It was smooth. It genuinely felt like coding in a notebook — I wrote the transformation I wanted, and the thing I expected to happen, happened, to the data. For someone who thinks in Python, that's a lovely feeling: no translating my logic into a language I'm less fluent in, just... writing Python and getting my shaped data out the other side.

The processing was surprisingly quick, too. I think that's partly because, unlike the Python visuals, a query-editor script doesn't have to render anything to show you it worked — there's less going on, so it feels snappier. If Python is your native tongue, you can absolutely see the appeal of moulding your data this way instead of reaching for Power Query M every time.

What's actually happening under the hood

A quick note on the mechanics, because it explains both the appeal and the limits. When you drop a Python step into the query editor, Power BI hands your current table to Python as a pandas dataframe — so the dataset variable you're working with is just a dataframe, and whatever dataframe you return becomes the next step in the query. If you've touched pandas at all, that model is immediately comfortable: table in, wrangle it however you like, table out.

It also quietly explains the performance worry I'll get to in a moment. Everything runs through Python and pandas on your machine, in memory, as an extra hop bolted into the query pipeline. That's perfectly lovely for a modest table you're reshaping. It's a lot less lovely as the row counts climb and that in-memory hop turns into the slow part of every refresh.

Verdict

So will I swap out Power Query M for Python in my day-to-day? Probably not — and coming from an actual Python person, that should tell you something.

Here's the thing. For dashboarding and reporting I mostly live in Azure Analysis Services, Power BI, and a bit of Excel, and in that world Power Query M is simply the more natural fit for the "clean and shape the data on the way in" job. It's built for exactly that, it lives natively in the tool, and it doesn't ask anything extra of the environment. Python being available in the query editor is delightful; Python being the right choice for this particular step, in this particular stack, is a higher bar — and most of the time M clears it more easily.

More reasons why

But it's not just personal preference. Even setting aside "which language do I like," I've got some concrete reasons I'm cautious about leaning on query-editor Python for anything serious:

  • The data privacy level has to be set to Public. This one genuinely gives me the shivers. To run the script, you have to mark the data source's privacy level as Public — and the idea of flagging organisational data, which might have something sensitive lurking in it, as Public just to run a transformation is not a trade I want to make casually. It's the kind of setting that's fine on a toy dataset and quietly alarming on a real one.
  • Performance at real scale worries me. The sample I tested on was small, so of course it flew. But the data I actually work with day to day is a lot bigger, and Power BI Desktop is just not where I'd choose to do heavy data processing — it's not built to be a big-data engine, and it shows once the row counts climb. That's exactly why I lean on Analysis Services for the heavy modelling in the first place. Python in the query editor doesn't change that calculus; if anything it tempts you to do processing in the wrong place.
  • Refreshing outside Desktop means a Personal Gateway. The moment you want this to refresh on a schedule in the service rather than just on your machine, you're into Personal Gateway territory — which means if your machine is off or offline when the refresh runs, it doesn't. Add the general fun of gateway credentials and re-installs, and it's enough friction that I'd rather not build anything I care about on top of it.

So there

None of this is me dunking on the feature — I want to be clear, because I came in genuinely rooting for it. It's a very cool addition, and for a Python person there's real joy in shaping data in a language you actually think in. If I use it, though, it'll mostly be for fun, or for a quick one-off where none of the concerns above bite. For the reports and models I have to trust and refresh and hand to other people? Power Query M stays. (Boy, that's a lot of Power Query M for one post. There, one more: Power Query M.)

But hey — that's just my two cents. Try it yourself; you might weigh the trade-offs differently, and for the right little job it's a genuinely nice tool to have in the box. ;-)