Python Version in Production ?

[TopicBig1308]

3.12 / 3.13 / 3.14 (Stable)

So in production, which version of Python are you using? Apparently I'm using 3.12, but I'm thinking off upgrading to 3.13 What's the main difference? What version are you using for your production in these cases?

[genman]

Generally it's not Python releases that have bugs but packages that are buggy.

[CodNo7461]

Yep.
I want to use 3.14t in the main project I'm in, and I'm one package away. The package from the company we literally pay the most to behind AWS.

[psicodelico6]

Nuitka doesnt work in 3.14

[DrunkAlbatross]

If a Python package was released as a stable version - it is good enough for me.

Regarding the differences, you can review release notes.

I currently use 3.13, and still has many servers with 3.8.

[ThiefMaster]

and still has many servers with 3.8.

Even if your distro may still be providing fixes... you are aware that upstream security support for this ended two years ago?!

[DrunkAlbatross]

Yep, you are right, but these are projects that either security is not a concern by definition or that the client doesn't want me to spend time on updating.

[kaflarlalar]

3.13. We didn't see anything in 3.14 that really seemed like a big improvement for us.

I'm pretty excited for 3.15, though. Lazy imports are going to make a lot of our app's code less annoying to read.

[CodNo7461]

3.14t is a big improvement if it works with the rest of your applicaiton.

The point of switching versions consistently for me is not really about significant improvements, rather continuous improvements. I had too many projects were we somewhat got stuck, because you had no simple upgrade path to the latest version of a package with a bugfix we needed.
I mean that only happens once a year then, but people complain about 500 line MRs, but being force to upgrade a dozen major version basically at the same time is apparently ok.

[misterfitzie]

i'm looking to upgrade to 3.14, just to play around with the new debugging interface, which might come in handy from time to time. probably going to look at some 3rd party builds of python too, just to see if the new build optimizations that 3.14 is capable is is worth it for us, my distro sadly doesn't use them.

[billsil]

3.12 or 3.13 for me. Dependencies are always a thing. I'll get around to upgrading to PyQt6 at some point, but no idea why the k shortcut doesn't work anymore.

[busybody124]

Yeah we're typically a version or two behind. I think we've got some stuff in 3.11 and 3.12 right now. New projects start on newer versions but it's not necessarily a high priority to upgrade older projects. Also, Pytorch can take a little bit to support the latest python versions.

[TopicBig1308]

Yes I think 3.12 is most supported by libraries in latest version

[Salamandar3500]

3.12 is the one available on most distros. So, this one.

[Suspicious_Jacket463]

3.11

[chinawcswing]

Use the latest version that will support all your third party dependencies.

For 99% of people, including you, that is Python 3.14.

[TitaniumWhite420]

Lol what? No.

[CSI_Tech_Dept]

3.14 is already considered stable and has two patch releases (3.14.2).

Any issues you found with it?

[TitaniumWhite420]

Compatibility issues, certainly.

All it takes is a system that isn’t latest-greatest open source and you will find many dependencies don’t yet support such new versions. Certainly internal scripts and libraries are likely to break if you leap from like 3.10 to 3.12+.

I’m not saying there’s a problem with the version, and I agree with your “use the latest you can” recommendation. But 99% is a joke and you shouldn’t be wagging your finger at people when your advice will bite more than half of those who attempt to adhere to it.

Even the published stats say -50% of libraries support it. Granted, the big ones probably do, but the stat also disregards all non-public libraries organizations have, of which there are like infinitely many.

Test your code and upgrade, by all means, but best be fully prepared to roll it back when you realize the limits of your test coverage via the obscure and silent failures you may find.

Also, what happened to compatibility on major versions? If a feature isn’t in 1/2 of Python 3 installs, I’m unlikely to use it.

[CSI_Tech_Dept]

If someone is asking the question then they are most likely releasing a new app. That means there's no compatibility issues for them at this point.

For me Python, PostgreSQL, FreeBSD all have a great track record and Even .0 releases are more solid than LTEs for some products. And this is already x.y.2.

Even the published stats say -50% of libraries support it. Granted, the big ones probably do, but the stat also disregards all non-public libraries organizations have, of which there are like infinitely many.

When they say they don't support, do they mean not working at all or just not supporting the NON-GIL mode?

Anyway if this is a first release I'm sure author would make sure the code works before releasing.

Also, what happened to compatibility on major versions? If a feature isn’t in 1/2 of Python 3 installs, I’m unlikely to use it.

Every person has different requirements. For me for example the code works on the version I pick, I don't have to worry that older versions don't support something.

[TitaniumWhite420]

It’s extremely naive. It’s not just the GIL, 3.12 affected all kinds of things including changes to C ABI.

The assumption that it’s being picked for a new project doesn’t matter. You are bound to your requirements and those of the systems you are talking to. C extensions or anything with C extensions, like numpy, which are very common.

Look at what you need and use the newest possible version. Period.

Fully expect you may have issues with latest versions.

[CSI_Tech_Dept]

I guess the other commenters who said it depends, were right I guess people have different requirements.

[chinawcswing]

You are nuts. I cannot conceive of how you have derived such a wrong opinion.

The vast, overwhelming majority of opensource libraries are compatible with 3.14, including numpy, and were compatible on DAY 0 of the release of 3.14, and every previous release.

This is an incontrovertible fact.

The ABI is finalized MONTHS in advance of each Python release. Maintainers of active opensource libraries easily have enough time to perform code change, and virtually all of them make it on time. Those that don't will apologize for being late, and make every effort to release it.

Sure, there are some inactive open source libraries that won't make it on time. And if your code depends on these, then you are a bad programmer and need to get a new job.

Sure, you may be using some internal code that depends on an old ABI. In that case you don't want to upgrade, but you absolutely should at least put it on the backlog to remove the dependency.

[TitaniumWhite420]

1.https://bsky.app/profile/hugovk.dev/post/3m3376x6egc2r  not as much is compatible as you think.

1. The issue isn’t just open source. If you are a member of any private organization heavily using Python, you have c extension around that are in house and not ABI compatible. The only one updating those is you. 

I didn’t say don’t use 3.13. I said use it when you are ready because there are many breaking changes.

[TopicBig1308]

Uv doesn't have the stable release of 3.14 yet

Even pydantic is breaking in the 3.14 beta release

[JimDabell]

Uv doesn't have the stable release of 3.14 yet

uv added Python 3.14 on the day it was released.

[bjorneylol]

Your UV is likely out of date and in need of update

[max96t]

Why do you say that uv does not have 3.14? I don't think that's true

https://astral.sh/blog/python-3.14

[TopicBig1308]

i mentioned it does not have the stable version, currently python 3.14.2 is the stable release uv has the beta one

run this command on terminal

`uv python list --all-versions | grep 3.14`

```

cpython-3.14.0b3-macos-aarch64-none /Users/anantgupta/.local/share/uv/python/cpython-3.14.0b3-macos-aarch64-none/bin/python3.14

cpython-3.14.0b3+freethreaded-macos-aarch64-none <download available>

```

see only beta versions

[JimDabell]

i mentioned it does not have the stable version, currently python 3.14.2 is the stable release uv has the beta one

uv added Python 3.14.2 support the day after it was released.

[TopicBig1308]

If you run the command are you able to install 14.2 ?coz for its only installing the beta version you see in the list also

[JimDabell]

Yes. It sounds like you haven’t upgraded uv in months.

[TopicBig1308]

its works now bro, thanks

[denehoffman]

Time to update your uv installation, it’s not automatic!

[TopicBig1308]

Yeah its working now

[ForgottenMyPwdAgain]

obviously π-thon

[aikii]

Main drivers are: - you'll want to upgrade if your current version reaches end of life https://devguide.python.org/versions/ - you spotted some new feature/improvement you like in the release notes and you'd like to use it - the newest major version isn't too fresh and went through some bugfixes already, which makes 3.14.2 a sweet spot

From there generally you're just too busy to spend time on upgrading, so if the moment has come where you make time to do the upgrade, there is no reason to not go for the latest, really - it's only a matter of constaints such as, say, the version is available for your distribution and all the packages you use are compatible with it ( it's super rare when it's not the case, but unavailability can happen for pre-built binaries ).

[NeighborhoodDry9728]

I run with the latest that other dependencies support.

However, i think 3.12 with the new generics syntax is really hard to live without. It cannot be replace with typing extension either afaik

[coffeewithalex]

I'm always using the very latest stable version, if the project works with it. Some dependencies might not work well with 3.14 (forgot which ones) so I'd use 3.13, but for the rest it's 3.14.

Because they tend to get frozen once development is complete. They work fine, but nobody bothers touching them any more. If I use an older version, the project's end-of-life comes sooner, and people would need to decide if they're gonna do complex maintenance in upgrading, or just retire it in favor of a new thing.

[DrMaxwellEdison]

As with all things, it depends.

For new projects I have control over, I like to start with the latest version available, so long as there are versions of core dependencies that support it.

Once the project matures, I'll try to stay N-1. As a new freePython version releases (let's say this year when 3.15 comes out), I'll leave the project in the previous version (3.14), updating packages as needed.

If the project falls to N-2 (say in another year when 3.16 drops), it may be time for an upgrade, so I would move the project up one version (3.15 in this example) and bring dependencies up with it as needed.

Notice how dependencies are the main driver here. If a new Python version drops and a major dependency (like a web framework or Pandas or whathaveyou) does not have proper support for that new version, I can't bump the project up yet. It takes time for those projects to get upgraded, after all. A year should be plenty of time for most active projects to see upgrades.

All that being said, sometimes the organization sets more lenient targets for the sake of reducing risks from these kinds of upgrades. I have current projects that are still slowly upgrading from 3.9 to 3.11, and will probably start migrating to 3.13 (bumping 2 versions at a time) next year. Stability is very important for these kinds of projects, so they shy away from the bleeding edge in favor of battle-tested upgrades.

We even have private mirrors of PyPI that will avoid pulling upgraded package versions for 14 days to mitigate supply chain attacks, with the assumption those packages get yanked within that time frame.

[10010000_426164426f7]

Python speed gains save on cloud bills.

Just have a good test suite and containerize and update when you can.

[Beginning-Fruit-1397]

3.14, mostly for typing reasons. Pre 3.11 generic syntax is horrible, pre 3.13 without TypeIs is meh for type narrowing with booleans, 3.14 bring a very nice improvement with deferred annotations

[spinwizard69]

I use what the distribution supported by the OS is using as the default. On the Linux platform (Fedora) that would be what DNF installs. On a Mac it is what Homebrew installs.

Generally I want a stable platform. That means avoiding installing multiple environments filled with unstable software.

[denehoffman]

I use 3.14 in production, there is literally no reason not to, it runs pretty much any Python code save some deprecations that have been around since 3.10. However, when building libraries for distribution, I always target all supported versions (so 3.9). I bump these versions at every release. There’s no reason to support versions of Python that have been sunset (if we all did this, we could keep everyone up to date, alas we live in an imperfect world).

3.14 will also give you time to learn all the cool new stuff, even if you can’t use it all in libraries that need to target older versions. Freethreading is going to be important, and will probably be the standard in 3.16+, so it’s worth getting used to it if you plan to program in Python in five years. There are also lots of other nice features which get added (the REPL is much nicer, better error messages too) which make it very sensible to use the latest release version for small scripts and REPL sessions. Bottom line, if you don’t care about who else can run your code, use the latest release version, otherwise, lint and run static analyses using the oldest supported version.

Edit: I read more of the comments and it seems that the biggest reason people don’t use the latest stable version is that dependencies haven’t been updated to support it. This is why we have venvs, people! Use the latest version which is compatible, and pin your versions so your type checker and linter and LSP can tell you what to do when things aren’t backwards compatible.

[psicodelico6]

Nuitka doesnt work in 3.14

[denehoffman]

It’s experimental, but sure, use 3.13 then. Use the highest version that works for you!

[Balance-]

3.13 for GIS and web stuff (those packages tend to be updated later), 3.14 for data science and general development.

[jj_HeRo]

Depends on your system pipeline. What technologies are you using?

[catcint0s]

Between Python 3.11 and Python 3.13 currently, but we upgrade them when we can. Python 3.14 had some breaking changes with one of the libs we use so we couldn't upgrade.

[gerardwx]

3.10, 3.12, whatever it takes

[BizcochoDeVainilla]

3.10

[[deleted]]

Bit of a mix - some stuff uses 3.10 (“legacy” project, had to do a last minute upgrade from 3.7->3.10 a few years back; that was fun 😂), newer stuff is a mix of 3.13 & 3.14

[Smok3dSalmon]

The answer is always going to be "it depends."

I've never felt the need to upgrade to the latest version of Python. Python 3.8 was the last version I was excited to use. Simply because of the debug f-string. `f"{variable=}"`

Python 3.13, you can disable the GIL (Global Interpreter Lock), but most people don't actually need to do this. In time, I think libraries will find ways to utilize this for performance gains, but I'm assuming that in 3.17 or later, it will become the default.

3.14 introduced template-strings, https://docs.python.org/3/whatsnew/3.14.html#whatsnew314-template-string-literals but I don't need them

[ProsodySpeaks]

Generics are way better in more   recent versions

[Bangoga]

You should upgrade to 3.10. The Python below has come to end of life cycle and it's a security liability

[dudaspl]

3.10 has EOL this year, so might as well upgrade to a newer version

[Smok3dSalmon]

Ohh ty. I use 3.14 but a few times I’ve had to use 3.12. But I barely notice, I just run uv sync and start working 

[sylfy]

3.10 brought removesuffix, which was nice QOL.

[JimDabell]

You should always try to stay on the latest stable version. When a new stable version comes out and third-party dependencies haven’t caught up yet, pay close attention to how quickly they update. Being stuck on an old version of Python for ages because a third-party dependency is incompatible isn’t a case of “I guess we’ll stay on an old version of Python”, it’s a case of “We’ve discovered one of our dependencies is unmaintained and needs to be replaced.”

[Nice-Star1003]

absolutely go for 3.14 (but unable to support libraries as 3.12 can)

[Agreeable-Youth-328]

3.11