The next big thing in Python

Where I pretend to know the future then cowardly avoid the topic

Summary

Python is surprisingly relevant in 2025 if you want to get things done. Not too shabby for such an old language, and if you look at how much it reinvented itself over the years, it’s even more impressive.

Now that provisioning is more or less a solved problem, what are the big challenges the language and community need to tackle?

No, that’s not going to be Web client scripting, sorry.

I put my bet on shipping to the end user and mobile support.

We had a good run

As I was reading a bluesky thread where people marveled at the fact Python is still holding up so well after so many years (remember, Python is OLD), I thought "true, but why?".

It's easy to fall into the trap of making up stories after the fact to justify some success. Maybe it was the guiding light of Guido, maybe it was an excellent design for its time, maybe its philosophy attracted just the right community, maybe it was just sheer luck, or a combination of all that and more.

What is certain is that Python didn't start like it is today. There were a lot of niceties already (see the article about compiling Python 1.0), but it has gone through a lot in three decades.

There was the transition between old-style classes to new-style classes (remember when we had to inherit from object all the time? That's why), the migration from string exceptions to a dedicated type (you could do raise "Woops" before that), and the introduction to real inheritance from built-ins (looking at you UserDict). We got the with keyword, the yield keyword, decorators, list comprehensions, 3 different argument parsing modules, and a hell of a lot of different packaging tools.

But, believe it or not, all that was already before the big earthquake, the transition from Python 2 to Python 3! This one took a good 15 years for the world to align with. I still have a client with a 2.5 code base, though. Some industries will make snails feel like speed racers.

This kind of event left Perl half-dead and forced PHP to abandon a whole version, but Python survived and even thrived. We got a lot more lazy processing, a whole new I/O API (with unicode as default. Well, mostly), print() obviously, better division, import, and inheritance semantics, and just generally a cleaner language.

Still, everybody swore on their mother, child, and dog that we would never do that again and that there would be no Python 4.

That didn't mean Python would stop evolving.

In fact, it kept a steady pace, and in the last 10 years, we saw the rise of pathlib, asyncio, f-strings (and soon the wonderful t-strings), the walrus operator, dataclasses, type hints, and fantastic QoL improvements on error messages, the debugger, and shell.

While better async facilities and the increased focus by the core devs and community on code quality tooling (mypy, black, ruff, the BOM, etc) really kept Python a legitimate option in the ocean of modern languages storming today, it's obvious to me that the biggest leap of all has been nailing down the bootstrapping and dependency story.

It's been a very long journey, this thing. easy_install, setuptools, distutils, setuptools2, a new installer, deadsnake, ensure_pip then venv in the stdlib, the move from eggs to wheels, the arduous introduction of pyproject.toml drop by drop, the years of getting feedback from pipenv/poetry/pdm/hatch/rye, the birth of the indygreg stand-alone builds, and finally, fast forward in 2024, the nuclear bomb, uv.

So that leaves you thinking...

What's next?

What's not next

Making good predictions is very difficult, and when you can't easily describe something because you lack data to do so, via negativa is a decent workaround. Ask all the religions in the world.

And I'm pretty confident about what Python will not become.

Python will not become the next client-side language. It will not replace JS, at least not at any meaningful scale.

I wish it could, but it's just not going to happen, even with WASM, even with pyscript.

JS is the only language that doesn't have to pay the price of a runtime inclusion, and it doesn't stop evolving either. By the time the pipes become so fast it won't matter anymore, Javascript will have improved proportionally and will maintain its Web native advantage over Python no matter what. It has overcome being one of the worst languages ever designed and has become decent, it’s not going to stop there.

Besides, there are so many competitors, like Gleam and Rust, that have a better WASM story than Python already, that even if JS didn't, it doesn't stand a chance.

But honestly, the real reason is that in 20 years, the Web is unlikely to be the main platform anyway, so it will not be worth investing in it, and efforts will dwindle. Think about how much we have seen since 2000: the web, the mobile, the AI... We don't know what will happen, but what's certain is that stuff will change. A lot.

Python will also never become a big contender in the video game industry. There have been some attempts, like with Civ 5 or X Plane, but mostly dev teams haven't found Python attractive, even as just a scripting language. No decent engine even has Python support currently, and Lua is still very popular. It's game over for games.

That doesn't mean Python having a webassembly target and pygame don't have great value. They do. I use them both, they are very useful. But I don't find them to be hints that the language will capture the market like it did in other areas. We are so used to Python being good at everything, it's easy to think this will happen all the time.

Python being a spec, you could technically create flavors of Python with different technical characteristics, like Pypy has done to add a JIT. Nevertheless, I think it's safe to say we will not see a "real-time" Python tsunami. You would need to remove too many things from Python that make it Python to achieve this goal. The way it does introspection, metaprogramming, memory safety, and C-binding makes it very difficult to do some other things.

Change too many things, and Python is not Python anymore. uPython, Pypy, and PyScript can't use many popular libs because they need to compromise, and they are the best players with the most compatible implementations.

Of course, you can do a bit of soft real-time with the language, play with GC pauses, have C libs do some of the heavy lifting, and be loose with your requirements, but again, that will be an occasional use case, not the "Python taking over the world" situation. Useful, certainly, but not the next big thing. Right tool for the job, after all.

But there are areas where Python could grow tremendously.

Please let me ship

When looking at the JIT, multi-interpreters and no-GIL builds, one would think speed is what the future looks like. And while I welcome those improvements, I don’t believe they will change how we use Python as much as one might imagine. Python was slower in 2005, and computers were much less powerful. It didn’t stop Google from rewriting YouTube in Python.

Rather, I’m turning my eyes towards more primitive issues.

Now that "install Python and the dependencies of my project" is more or less taken care of, there is still a step in the story of packaging that leaves to be desired: delivering your app to the end user.

There are many projects that try to solve this: pyinstaller lets you create a standalone Python executable, briefcase to build and sign installers for many OSes, Nuikta to literally compile your program, and many others.

Yet, there is a reason most people choose to go the web route with Python: if you ask the average programmer how to share their work with others, you'll get a thousand different answers at best, or a big "???" blinking above their head at worst.

Compared to Go or Rust, it's a hurdle. And it's getting harder.

Harder because there are more and more platforms nowadays. More OSes, more device types, more CPU architectures... But also more security measures, more package formats, and more restrictions on how the typical person can install stuff. Not to mention, the explosion of locked ecosystems, often through so-called stores. Even if you manage to make a beautiful dmg/exe/deb of your program, you have to sign it in multiple ways, put it online 10 times, and fight with the various review processes so that it stays that way.

Of course, this gets more interesting if what you need to ship requires more than Python. How do you vendor that? What happens to the signing process? How does that affect your security rating? So much fun.

The need is growing as the user base of the language is expanding. It's important for beginners because they can't deal with the new complexity, and for professionals, who have quality and security requirements that make hacking a solution unappealing.

Plus, nobody wants to spend time on this. People want to create cool stuff, not reinvent the square wheel of shipping again and again.

I'm half expecting that something will use UV to provide some kind of "on-the-fly" installer solution. It would be a good start, but not something that would work behind corporate walls, and a no-go for most app stores anyway. I'm aware of two attempts already.

To be honest, I have no way to know if this is the next big thing in Python. But I'm strongly convinced it needs to be one of the next big things if we want the language to keep being awesome in the coming 20 years.

I know it's not fair to expect Astral to save us again from our sins; they've done so much already. But given that their business model is to provide a B2B packaging solution, it would make sense to be part of their strategy eventually.

After all, Anaconda is certainly heading that way.

Are we mobile yet?

If you follow the previous link, you'll end up on Russell Keith-Magee's interview in which he says something obvious but that clearly needed to be stated out loud: the new generation is not on PC, it's on phones and tablets, and it makes sense they want to develop for their favorite devices. Even **on** their favorite devices, no matter how awful that sounds to me.

Python mobile abilities have been quite limited so far.

Yes, there are official Android and iOS build targets, but they are still Tier 3, so non-release blocking.

The UI toolkit story is equally limited. Right now, if you want to dev for a smartphone with Python, you either go Kivy (limited number of widgets, intimidating setup experience, bad windows support), flet (super new, based on flutter, a tech with an uncertain future), and toga, which only supports a restricted subset of use cases on purpose.

And then things get complicated if you want to use c-extensions, background processes, and subprocess calls to third-party vendored tools like ffmpeg.

Just like with providing an installer, it is possible to write a mobile app with Python. It's just a painful experience compared to the competition. Pure Flutter and React native are winning the race.

Not to mention Python apps are less responsive compared to them, saying nothing about native objective-C/Swift or Java/Kotlin apps.

There is also no good synchronisation ecosystem for Python, so your offline-first experience must be provided manually every time. Even the CRDT bindings are not great, and it's only part of the tools you need.

The mobile limits in Python echo the UI limit of the language in general. QT, GTK, and Wx bindings are showing their age, and really can't hold a candle to modern graphics Web toolkit when it comes to available FOSS components. We can all hate on bloated electron apps, but at least their interfaces don't feel like the 90s just crashed, drunk, on your secondary screen.

I'm hoping the salvation will actually come from the Rust world on this one. They are experimenting with a lot of different UI solutions, and mobile is a goal. And since Python and Rust are BFF now, we could ride this wave.

What are we going to do tomorrow night?

The same thing we do every night, dear reader: try stuff and see if it sticks.

Obviously there are other big things in our future, and probably in the future of Python. I certainly didn't see the popularity of Python in AI coming, so I'm not going to pretend I'm an oracle.

It would be foolish to limit ourselves to working on only two topics: mobile and shipping experience.

But I'm sure those are important, and if you are looking for something to work on right now, they are very worthwhile roads to travel.