Bump min python 3.9 (because py3.8 is End-Of-Lifecycle)

[Borda]

Description

Since python 3.8 is not actively maintained any more, would it be good idea to bump it to 3.9? I am happy to help and likely split it into two PRs, one with package and requirement update and second with liner update (which will be likely larger diff).

Update: my apologies for starting this big argument...

[rodja]

Thanks for bringing this up @Borda. We would really appreciate your help in bumping Python to minimum version 3.9. Please feel free to create pull requests.

[ed2050]

Please no. Some of us still use 3.8 for foreseeable future. 🙏

[ed2050]

DO NOT WANT!!!

Some of us are stuck on python 3.8. Systems that work perfectly fine have no need to upgrade their python system just because python devs can't be bothered to support it anymore.

What does end of lifecycle even mean for python??? Not like it needs critical fixes much. Apple still ships with python 2.7 by default (3 also available but not default).

How about nicegui requires the version of python with features it needs, instead of some arbitrary cutoff? If you want to recommend version 3.9+, sure. No problem. But don't break things that work just because you don't like a digit somewhere.

The endless upgrade treadmill is the bane of modern computing.

[8forty]

@ed2050 Yikes, we get it that you have strong opinions on this topic but there's no need to be condescending is there? Your experiences and needs don't match mine (or others here obviously), personally I love some of the python updates since 3.8.

I'm glad the team is working to move to 3.9 and beyond, in my opinion it will allow improvements in the code.

[ed2050]

@8forty I was trying (and apparently failing) to be gentle. Sorry for coming across condescending. Text medium loses nuance.

Differing opinions are fine. If I argue strongly, it's because I want to be clear since others don't see an issue. Hopefully I gave people a new perspective to consider.

Cheers and happy new year. 🍻

[frankvp11]

It'd be interesting to see NiceGUI on the new version where you can get past the GIL and have proper multithreading. I imagine it would be useful, but I don't know nearly enough about it to do much

[Alyxion]

Aye 😄 ... old enough that in 25 years of professional software development I learned that embracing new technologies and continuous care of the code base usually pays out in the short as in the long term - while trying to stick to software or tech at or beyond the end of the lifecycle usally backfires earlier or later.

Python is for free.

Why would one not take advantage of the performance improvements of 3.11 & 3.12?
Why would one not embrace the new f-strings, type hints, pattern matching etc.?

And no - we could not use Python 3.2, we are building industrial and cloud solutions, usually all of the packages involved, be it tensorflow, pandas, keras are all >=3.9 already, numpy is actually even already sticking to >=3.10.

So you're condeming all future python 3.8 users to be stuck with the current nicegui feature set forevermore.

Nobody is condemned, nobody needs to die. sudo apt-get install python3.12 or visiting https://python.org and doing it the manual way - 5 minutes - sentence reversed. And that even on a 12 year old Windows Vista notebook which would also still support Python 3.9.

And most importantly...

future Python 3.8 users?

I know a dozen professors who teach Python, mentored many students myself and be assured, no new student, at least in western europe, will get the recommendation to download Python 3.8 in year 2025 by any professor.
Why should the universities do such a thing? They want their students to learn modern Python, they want their students to succeeed in job interviews and yes, things like advanced f strings, type hints, match case etc. can for sure be a part of such a job interview.

Why should any other random "future user" who starts with Python download 3.8 if even the official Python website says end of life in big letters next to it?

Anyways, potentially endless discussion and my last post in this thread. Happy new year everyone 👍 .

[ed2050]

Aye 😄 ... old enough that in 25 years of professional software development

Almost the same age then. I understand your points. You're used to working in environments where you have complete control of your machine. In many places that's not the case.

I've worked in universities, in corporate settings, in government institutions in US and Europe. Rarely do you have the freedom to install software on your own machine, let alone any servers. The environment is fixed and tightly controlled. You're lucky to get any python, let alone a recent version.

You might have python from 5-10 years ago when one of the IT guys needed it bad enough to jump through all the compliance and security vetting hoops to get it added to the desktop / server base image. No one's updated it since. Ask the IT guys to update it and they'll laugh - they have a million other things to do and no time or interest in doing a painful compliance review just to bump a few minor versions.

When you work in environments like this, yes upgrading to a new free version of python is a Big Deal. It doesn't happen. I've tried many times for more significant upgrades, it's wasted effort. So you live with what you have and do the best you can.

Python is for free.

Only if your time is free. There's always a cost in upgrading. Usually minimal, but sometimes not.

Why would one not take advantage of the performance improvements of 3.11 & 3.12? Why would one not embrace the new f-strings, type hints, pattern matching etc.?

F-strings - great. Pattern matching - meh. Type hints, just clutter imo - for automated tools, not people. Type hints make code a disaster to read. But that's me. Python documentation in general is poor at API reference.

I would use f-strings. After that python is getting too cluttered. From a basic readable language to a C++ everything-and-the-kitchen-sink disaster. They keep adding operators and eventually it will read like Perl line noise.

New isn't always better. There's a learning cost to adding all this new cruft. Developer time is more valuable than chasing down every new whiz-bang feature. Turing-complete is Turing-complete. Leave well enough alone.

There are pain points in python I would fix. But python devs have no interest in those. Just adding new bells and whistles.

That's my opinion. Not saying others should agree. Just answering your question of why anyone wouldn't want newer versions.

And no - we could not use Python 3.2, we are building industrial and cloud solutions, usually all of the packages involved, be it tensorflow, pandas, keras are all >=3.9 already, numpy is actually even already sticking to >=3.10.

Ok great. That's your environment. I never said everyone should stay on 3.8. I simply want users to have the choice. 3.12 works for you. 3.8 works for me. Can't we just be friends and play nice with each other? You can have your pattern matching and type hints, and I can ignore them.

Nobody is condemned, nobody needs to die. sudo apt-get install python3.12 or visiting https://python.org and doing it the manual way - 5 minutes - sentence reversed. And that even on a 12 year old Windows Vista notebook which would also still support Python 3.9.

Oh what an open environment you live in. If only the whole world was this way.

I know a dozen professors who teach Python, mentored many students myself and be assured, no new student, at least in western europe, will get the recommendation to download Python 3.8 in year 2025 by any professor. Why should the universities do such a thing? They want their students to learn modern Python, they want their students to succeeed in job interviews and yes, things like advanced f strings, type hints, match case etc. can for sure be a part of such a job interview.

Of course if you're starting from scratch, use the latest. People don't always have that luxury.

BTW any job interview asking about programming language features is a joke. Programming is about how to think. Syntax is a footnote.

Why should any other random "future user" who starts with Python download 3.8 if even the official Python website says end of life in big letters next to it?

Because future users don't always have control of their environment.

Anyways, potentially endless discussion and my last post in this thread.

I don't want to belabor the discussion either. But you clearly haven't understood where I'm coming from yet. Hopefully this post explains it.

[ed2050]

I'm all in favor of warnings. It would be great for nicegui to output a console message that says "warning: python 3.8 is no longer being updated. consider upgrading to a supported python version."

What I object to is nicegui refusing to run when python < 3.9. It's not any library's business what python version the user chooses to run. Library doesn't know the user's environment or limitations. Sometimes unsupported versions are ok. It's the user's choice to make, no one else's.

Version requirements should only be for technical reasons, such as: python 3.9 introduced feature X which nicegui really needs, and there are no suitable alternatives to X in lower versions.

[frankvp11]

I don't believe that upgrading to 3.9 would make it so that you can't use it on 3.8... not entirely sure though.

[Borda]

It would if linter would be set for 3.9+ since the typing changes are not back compatible...

[falkoschindler]

Thanks, everybody, for this interesting discussion! We didn't think this would be such a hot topic. But apparently Python 3.8 is still widely used.

I think, we can agree that NiceGUI would need to drop support for Python 3.8 if there were solid reasons to do so. At the moment, when looking into the code base, we don't think there are any. Some type hints here and there could be simplified, removesuffix doesn't exist in 3.8... nothing which significantly clutters the code or complicates maintenance.

Let's use this opportunity to discuss critical reasons for which it would be necessary to move on to Python 3.9. What would be the decisive factor for dropping an old Python version?

[ed2050]

Well to start off, I would suggest to upgrade to higher version when it has features that:

1. Can't be efficiently replicated in lower version; AND
2. Provide significant improvements to nicegui in functionality or code maintenance

That raises the question of "what is significant?" To some extent it's in the eye of the beholder. We could try to define significant. Or we could trust @falkoschindler and @rodja and others at nicegui to make a good decision. I'm comfortable with that. They know best what the pain points are in current code, and what advantages new features would have for the codebase.

A note on new functions - these can often be added to older versions cleanly. For instance, I was using python 2.4 when any wasn't yet available. Simple fix:

if 'any' not in globals () :
    def any (func, seq):
        return reduce (lambda x,y: x or y, map (func, seq), False)

The nice part is, when python is upgraded to a version with any, the local def is simply not used.

[evnchn]

So it is similar to the concept of polyfills on the browser, right?

It could be an interesting idea, but not all features can be worked around I think.

In the case of speed uplift with new version, I also recommend to use conditional imports and try-except, so as to not have it seem like older version becomes the common factor of speed. (This will become relevant eventually as the free-threaded mode catches on!)

[evnchn]

Stumbled across https://pypistats.org/packages/nicegui

Apparently 3.8 still accounts for quite a few percentages of downloads. Although it's in the single-digit, it's not nothing.

In fact, the download percentage of 3.8 is round the same ballpark of magnitude as 3.13 (quite surprising to learn).

On some days 3.8 downloads are more than 3.13, even.

Let's keep this in the back of our minds when we want to make decisions of any kind.

[evnchn]

Was scrolling through GitHub and the internet, when I had 3 important realizations:

Past poll on Python 3.7

There was a poll in #982 for Python 3.7. For that, the results were overwhelmingly in favor (81%) of timely deprecation of Python 3.7 when the End-Of-Life hits. Besides the daily download percentage and global usage percentage,

Let's bear this poll in mind for 3.8, for:

1. If we are lazy we can assume (with a big grain of salt) that we want to deprecate it in time, which we are already late by 7 months
2. If we are not lazy we can start another poll.
3. It may be a good exercise to check if the claims for keeping 3.8 makes sense, by casting them to 3.7 instead and think.

Which OSes held on to which Python version?

Talking about major OSes and their Python compatibility: Python 3.8 is a watershed version for Windows 7, where on Windows acceptance on building Python from scratch is much lower, though there is unofficial build up to 3.13.

We should also bear this in mind.

1. Debian 10 Buster ships Python 3.7,
2. Debian 11 Bullseye ships Python 3.9, though there is backport for Python 3.10 https://github.com/pascallj/python3.10-backport (although read-only now, and the packages repository may be gone, still can fetch deb from GitHub)
3. Windows 7 is only compatible with Python 3.8 and lower, unless you go for unofficial builds like https://github.com/adang1345/PythonWin7

a. @Alyxion By "Windows Vista notebook which would also still support Python 3.9", do you include unofficial builds? I can't find an official build of Python 3.9 which supports Windows 7 let alone Windows Vista.

b. @ed2050 Though it's likely a Yes, I want to confirm if you are on Windows, or speaking on behalf of Windows users. I'd like to know if we can accept the compromise, if we have (albeit from someone else) unofficial build of Python up to 3.13 for Windows 7.

Action statistics from the main VS my branch, and what we can learn from them

Consider Action runs of the main branch, https://github.com/zauberzeug/nicegui/actions/metrics/performance?sort=failureRate&tab=jobs, actually the failure rate of Python 3.12 (6%) is highest for some reason, then 3.9 (3%), then 3.11 (3%), as of writing. We know @falkoschindler* and @rodja* always check their code against a working type-checker.

Meanwhile consider Action runs of my branch https://github.com/evnchn/nicegui/actions/metrics/performance?sort=failureRate&tab=jobs, it's 3.8 (22%), 3.9 (21%) and 3.10 (16%), and I let GitHub Copilot free-style the code, push and check the action results and correct my code from there

1. Can I conclude that, if NiceGUI deprecates 3.8 and 3.9, the better type hints would not have great benefit, if we expect all contributors to set up their coding environment appropriately?
2. If not, are there solid benefits which newer Python versions enable, in terms of developement ease or new features?

---

Overall, though, since as new as Python 3.13 is available unofficially for Windows 7, and I'd imagine Linux (as old as Bullseye) people are fine with compiling CPython themselves & they have the backport of 3.10 at the very least, that I would personally recommend not only dropping 3.8 for the upcoming 3.0 release due some time, but potentially going one step further by dropping Python 3.9 as well, aligning with NumPy and other Python 3.10+ libraries, so that:

• We skip a step in migrating codebase from 3.8+ to 3.9+ to 3.10+.
• We force Windows 7 users to reconsider their life decisions and engage in using the unofficial backport, which they will have to in the future anyways, so let them do it earlier.
• Speed up GitHub Actions as we test less versions. It'll be 33% faster, I'd imagine.

Action items:

• Start a poll
• Collect why people hold on Python 3.8 and check if it is resolvable with unofficial builds given OS + Version combo
• Collect new features or beneficial items came about with the dropping of Python 3.8 (and maybe Python 3.9) support.

*mention is sort of intentional because I'd like you two to check if what I am writing here is correct. This feels like big deal.

[ed2050]

1. Why would you drop support for perfectly working, functional versions of python that people still use? Your own data shows 3.7 and 3.8 are still latest officially-supported python on many systems.

2. What is the benefit of switching to 3.10+? What features in it will improve nicegui's codebase, and how significant is the impact?

Dropping versions should not be a popularity contest. There should be good technical reasons (including maintenance & support issues) to do so.

[evnchn]

Still, I have created a poll at #4738.

Personally believe that a poll does not make "Dropping versions a popularity contest.", with my trust on Falko and Rodja's good decision-making abilities.

[falkoschindler]

I don't think we should drop versions that are still officially supported. This wouldn't be nice for people stuck with older versions for whatever reason. But as stated before: If there is a good technical reason to drop outdated versions, we don't have to keep them alive. E.g. when upstream dependencies like FastAPI require 3.9, we might want/need to switch as well.

[evnchn]

Thanks @falkoschindler for inspiring me to diff the venv.

After reviewing the packages, I think dropping both 3.8 and 3.9 is a bit too agressive, and we have to think carefully should we want to proceed (and let's establish drop 3.8 before considering dropping 3.9).

3 packages we use (albeit indirectly) dropped 3.8:

• MarkupSafe requires Python 3.9 from 3.0.0 release: dropped 3.8 one day before EOL pallets/markupsafe@9372f38
• watchfiles requires Python 3.9 from 1.0.0 release: dropped 3.8 one month after EOL samuelcolvin/watchfiles@e493e75
• websockets requires Python 3.9 from 14.0.0 release: dropped 3.8 one month before EOL python-websockets/websockets@44ccee1

Since none of those are direct dependencies, users can reasonably expect NiceGUI to continue to work, unless they invoke those dependencies directly AND there is breaking change which we jumped on and our pytest didn't catch (none so far).

Other than that, 18 other packages dropped Python 3.8 support in a minor release, and their next major release could break us.

pip freeze result of 3.8 and 3.12

3.8 venv pip freeze:

aiofiles==24.1.0
aiohappyeyeballs==2.4.4
aiohttp==3.10.11
aiosignal==1.3.1
annotated-types==0.7.0
anyio==4.5.2
async-timeout==5.0.1
attrs==25.3.0
bidict==0.23.1
certifi==2025.4.26
charset-normalizer==3.4.2
click==8.1.8
colorama==0.4.6
docutils==0.20.1
exceptiongroup==1.3.0
fastapi==0.115.12
frozenlist==1.5.0
h11==0.16.0
httpcore==1.0.9
httptools==0.6.4
httpx==0.28.1
idna==3.10
ifaddr==0.2.0
itsdangerous==2.2.0
Jinja2==3.1.6
markdown2==2.5.1
MarkupSafe==2.1.5
multidict==6.1.0
nicegui==2.17.0
orjson==3.10.15
propcache==0.2.0
pscript==0.7.7
pydantic==2.10.6
pydantic_core==2.27.2
Pygments==2.19.1
python-dotenv==1.0.1
python-engineio==4.12.1
python-multipart==0.0.20
python-socketio==5.13.0
PyYAML==6.0.2
requests==2.32.3
simple-websocket==1.1.0
sniffio==1.3.1
starlette==0.41.3
typing_extensions==4.13.2
urllib3==2.2.3
uvicorn==0.33.0
vbuild==0.8.2
wait_for2==0.3.2
watchfiles==0.24.0
websockets==13.1
wsproto==1.2.0
yarl==1.15.2

3.12 pip freeze

aiofiles==24.1.0
aiohappyeyeballs==2.6.1
aiohttp==3.11.18
aiosignal==1.3.2
annotated-types==0.7.0
anyio==4.9.0
attrs==25.3.0
bidict==0.23.1
certifi==2025.4.26
charset-normalizer==3.4.2
click==8.2.0
colorama==0.4.6
docutils==0.21.2
fastapi==0.115.12
frozenlist==1.6.0
h11==0.16.0
httpcore==1.0.9
httptools==0.6.4
httpx==0.28.1
idna==3.10
ifaddr==0.2.0
itsdangerous==2.2.0
Jinja2==3.1.6
markdown2==2.5.3
MarkupSafe==3.0.2
multidict==6.4.3
nicegui==2.17.0
orjson==3.10.18
propcache==0.3.1
pscript==0.7.7
pydantic==2.11.4
pydantic_core==2.33.2
Pygments==2.19.1
python-dotenv==1.1.0
python-engineio==4.12.1
python-multipart==0.0.20
python-socketio==5.13.0
PyYAML==6.0.2
requests==2.32.3
simple-websocket==1.1.0
sniffio==1.3.1
starlette==0.46.2
typing-inspection==0.4.0
typing_extensions==4.13.2
urllib3==2.4.0
uvicorn==0.34.2
vbuild==0.8.2
wait_for2==0.3.2
watchfiles==1.0.5
websockets==15.0.1
wsproto==1.2.0
yarl==1.20.0

[falkoschindler]

Note that there are two Dependabot alerts that don't seem to be resolvable for Python 3.8:

• https://github.com/zauberzeug/nicegui/security/dependabot/47
• https://github.com/zauberzeug/nicegui/security/dependabot/48

Both require updating to urllib3 version 2.5+, but version 2.3 dropped Python 3.8 support.

Also, consolidating pip and poetry might require Python 3.9: #4872

[evnchn]

I don't think dependabot alerts are publically accessible, but I get the gist: Python 3.8 will be stuck having that vulnerability, since it needs a patch for a library from a version it doesn't support.

I guess this is why EOL dates are there: they provide a time where everyone should (ideally simultaneously) stop supporting that version, so that nobody will be stuck in this scenario.

Conversely, since we are currently supporting 3.8 well beyond EOL, I guess this is what we get 🤷🏻‍♂️. All but adds weight to dropping 3.8 in NiceGUI 3.0.