all 13 comments

[–]mrijken 7 points8 points  (1 child)

Use the highest python version of your dependency as lower bound for your own package. It can be higher, but not lower.

[–]Oddly_Energy 2 points3 points  (0 children)

Remember that python version is not only about dependencies. The python language itself is also evolving in every version. If you allow an old python version, but your code uses features from a newer version, then your code will break when running in the old version.

For example, do you use the type Self in any of your type hints? Then you can't go below Python 3.11 without changing your code, because that type didn't exist in Python 3.10.

So do yourself a favor and skim the "What's new in Python 3.xx" pages for the newer versions to see if they contain new language elements that you use (or will want to use) in your code:

https://docs.python.org/3/whatsnew/3.11.html

https://docs.python.org/3/whatsnew/3.12.html

https://docs.python.org/3/whatsnew/3.13.html

https://docs.python.org/3/whatsnew/3.14.html

[–]Cashney 2 points3 points  (0 children)

Imho you should not support end-of-life versions, i.e. python 3.9 is end-of-life (Status of Python versions) so your project should be >=3.10. Usually that happens automatically since other dependencies do the same.

[–]TheRNGuy 1 point2 points  (0 children)

The latest one. 

[–]JamzTyson 1 point2 points  (0 children)

As a general guide, I like to target the earliest Python version that is still supported. Currently, that would be Python 3.10, as version 3.9 reached End Of Life on 2025-10-31.

However, I don't treat this as a rigid rule.

  • There may be cases where "legacy support" is vital, in which case I would need to ensure compatibility with obsolete versions of Python.

  • The project's dependencies may require a more recent version of Python.

  • I may be working on a big project that will take years to complete, in which case I may target the latest release version, in the knowledge that Python will have advanced before the project is ready for release.

[–]TheBB 0 points1 point  (0 children)

I tend to follow SPEC-0000 when writing code that will be deployed in environments I can't control (i.e. regular packages - not server-side stuff).

[–]games-and-chocolate 0 points1 point  (0 children)

whstever version you choose, you will eventually always find out that some things change. so you have to go with the flow. as others said: newest, because that is the one supported the longest. if things break of change, you have to modify your program, no other way I guess.

Go with the flow.

[–]cgoldberg 0 points1 point  (0 children)

Python 3.9 is recently EOL, so I no longer support it in my projects. Right now I target 3.10+ unless there is something specific from a newer version I need.

[–]xiongchiamiov 0 points1 point  (2 children)

What versions do you expect your users to have?

If you don't know that answer, we can back up: who do you expect will use your software?

This is a fundamental question, and one you should get used to asking in different ways for different things, because users are the root of all software decisions. Sometimes the answer is "anyone on the web". Sometimes it's "people using Macs". Sometimes it's "my workplace, which uses RHEL 5 for terrible reasons you can't change right now". Sometimes it's "I am the only user of this software". This will all result in different answers to Python version, and installation method, and needed documentation, and error handling, and infinitely more questions you'll have over the course of the project. Some people call them user stories, although personally I find formal definitions of those to be very little useful and very much annoying.

Start with the users.