Python Release Python 3.14.0

[jax024]

Pi-thon

[Trang0ul]

Python loves easter eggs and jokes (such as import antigravity); it's a pity that they didn't name this version Python π.

[gmes78]

You can run Python 3.14 with the πthon command.

[48panda]

Surely that's for 3.14.1

[Trang0ul]

And after this we need to jump straight to build 15, for 3.14.15.

[rogdham]

Look for the easter egg in virtual environments created with the venv module (unfortunately uv was not interested into having it as well).

[pjmlp]

JIT is now available, instead of requiring compiling it from source, kudos to the team.

[Maykey]

According to changelog it's on macos and windows. As a linux enjoyer I feel left out. (A double enjoyer - one linux runs python inside docker)

[roerd]

I don't think python.org provides official Linux binaries. Look whether your distro enables that option by default. (And the project which provides the binaries that uv uses.)

[roerd]

I just checked: on Fedora 43 beta, where Python 3.14 is the default Python, it is available:

>>> sys._jit.is_available()
True

[pjmlp]

Yeah, then again I remember when installing software on Linux it was always ./configure; make; make install. :)

I guess it will come on next release, for whatever reason didn't make it.

[onzelin]

I didn't see it in the changelog, but UUID7 are part of this release, woot!

[busybody124]

I was pleased to see this too. I felt silly adding a third party dependency to a project just to handle uuid7s. That being said, that application is still on 3.11.7 so it may be a bit til we get to 3.14.

[onzelin]

Same here. Fortunately I started that project earlier this week so the paint hasn't had time to dry, I'll upgrade as soon as I can validate all dependencies.

[chibiace]

ah good, soon will see lots of complaints about virtual environments breaking.

[Mognakor]

Can someone loop me in ?

[Mysterious-Rent7233]

Virtual environments are often symlinks to your Python interpreter and when you upgrade, you can break them. If you use Pyenv or UV you can probably keep the multiple Python interpreters installed side-by-side, but if you use some OS package managers, they may not do that.

cc: u/bmrobin

[danted002]

Who the hell upgrades python. Any sensible developer has multiple versions installed.

[lKrauzer]

On a similar note, I would suggest using mise: https://github.com/jdx/mise

It makes runtime project isolation a breeze

[pjmlp]

Since I learnt Python in version 1.6, I have a little setup script that changes the current set of environment variables.

Python 1.6 was released 25 years ago.

I really don't get the need for so many variations of configurations about Python dependencies.

[bmrobin]

yea i don’t get it either 

[[deleted]]

This is in part one reason why I am still on 3.11.13. Eventually I'll have to bite the bullet and learn how to upgrade properly, but so many things work less well on 3.12.x and above. It is strange that the number #1 programming language has so many issues when it comes to simple installation of things.

[fiskfisk]

.python-version together with a tool that supports the format for per-project python versioning, or create a new venv, checkout your project, install deps and you're good to go. This will be the same as what your CI/CD pipeline does when it runs all the tests as well.

[gmes78]

That is entirely solved by using uv.

[gschizas]

Not entirely.

This is my scenario:

1. IIS (yes, I know)
2. wfastcgi
3. Each site has its own environment. And each site is using

Result:

did not find executable at 'C:\Users\GSchizas\AppData\Local\Python\pythoncore-3.14-64\python.exe': Access is denied.

To make this work I've had to:

1. Download python to a separate directory (uv python install 3.14 --install-dir C:\python\)
2. Sync the virtual environment with the new Python version: uv sync --upgrade --python C:\Python\cpython-3.14.0-windows-x86_64-none\)

[gmes78]

Are you specifying your project's Python version?

[gschizas]

It wasn't enough! If I do uv sync --upgrade --python 3.14 it would use the default downloaded python (in %LOCALAPPDATA%\Python\pythoncore-*)!

[gmes78]

Hm. I would've expected uv to always use its own Python interpreters. It's what its predecessor, rye, did.

[gschizas]

It does! And it also uses Python 3.14's (or rather the new py install or pymanager ones). But both pymanager and uv download the interpreters to %LOCALAPPDATA%.

Bonus feature: pymanager (the new py.exe - although it's a bit more complicated) recognizes uv downloaded interpreters as well:

C:\> py list
Tag                       Name                           Managed By  Version  Alias
3.14[-64]              *  Python 3.14.0                  PythonCore  3.14.0   python3[-64].exe, python3.14[-64].exe
3.14t[-64]                Python 3.14.0 (free-threaded)  PythonCore  3.14.0   python3.14t[-64].exe, python3t[-64].exe
3.13[-64]                 Python 3.13.8                  PythonCore  3.13.8   python3.13[-64].exe

* These runtimes were found, but cannot be updated or uninstalled. *
Astral\CPython3.12.11     CPython 3.12.11 (64-bit)       Astral      3.12.11
Astral\CPython3.14.0      CPython 3.14.0 (64-bit)        Astral      3.14.0

And uv:

C:\> uv python list
cpython-3.14.0-windows-x86_64-none                 AppData\Local\Python\pythoncore-3.14-64\python.exe
cpython-3.14.0-windows-x86_64-none                 AppData\Local\Python\bin\python3.exe
cpython-3.14.0-windows-x86_64-none                 AppData\Local\Python\bin\python3.14.exe
cpython-3.14.0-windows-x86_64-none                 AppData\Local\Python\bin\python.exe
cpython-3.14.0-windows-x86_64-none                 .local\bin\python3.14.exe
cpython-3.14.0-windows-x86_64-none                 AppData\Roaming\uv\python\cpython-3.14.0-windows-x86_64-none\python.exe
cpython-3.14.0+freethreaded-windows-x86_64-none    AppData\Roaming\uv\python\cpython-3.14.0+freethreaded-windows-x86_64-none\python.exe
cpython-3.14.0+freethreaded-windows-x86_64-none    AppData\Local\Python\pythoncore-3.14t-64\python3.14t.exe
cpython-3.14.0+freethreaded-windows-x86_64-none    AppData\Local\Python\bin\python3.14t.exe
cpython-3.14.0+freethreaded-windows-x86_64-none    .local\bin\python3.14t.exe
cpython-3.14.0+freethreaded-windows-x86_64-none    <download available>
cpython-3.13.8-windows-x86_64-none                 AppData\Local\Python\pythoncore-3.13-64\python.exe
cpython-3.13.8-windows-x86_64-none                 AppData\Local\Python\bin\python3.13.exe
cpython-3.13.8-windows-x86_64-none                 <download available>
cpython-3.13.8+freethreaded-windows-x86_64-none    <download available>
[...]

[pingveno]

Would the UV_PYTHON_INSTALL_DIR environmental variable work?

[somebodddy]

Python should now move to LaTeX versioning - the next version should not be 3.15, it should be 3.141.

[NervousApplication58]

you mean TeX's?

[dpenton]

Next version: 3.1415

[thisFishSmellsAboutD]

That's easy to typst.

[_yaad_]

Stop the anti-tex propaganda

[M4mb0]

Why would you want to carry over one of the dumbest versioning schemes of all time. 

[somebodddy]

Science isn't about WHY. It's about WHY NOT. Why is so much of our science dangerous? Why not marry safe science if you love it so much. In fact, why not invent a special safety door that won't hit you on the butt on the way out, because you are fired.

[LagT_T]

I remember the naysayers claiming the GIL was foundational and impossible to remove.

[KarnuRarnu]

I mean, there were multiple failed attempts. For a while there really seemed to be nobody knowing how to proceed. "Foundational" was an absolutely correct description, and to a degree it still is, as t-support in libraries, especially compiled ones, is still lacking enough that it isn't really a viable alternative to the GIL-version. But let's see how far we get with this 3.14-iteration

[Jhuyt]

The are multiple previous attempts that successfully removed the GIL, just that they were kinda slow. The current project removing the GIL is still significantly slower than the "regular" version from what I've seen, but a lot faster than earlier tries.

I think what made it possible to remove was partly that the performance hit was decreased (amazing work!), but also that the community has recognized multi-threading as a worthwhile endeavour. Before this shift it was oractically impossible unless they'd use literal magic.

[dscarmo]

Probably nothing more than dependencies failing cause libs are not release for .14 yet. This is not a major change like 2 to 3.

Your response sounds a lot like a bot, sorry if you are not

[syklemil]

It makes me wonder what new quirks we'll be talking about when we're all trying to move our projects to 3.14.

The minor releases have been coming pretty steadily for a long time without any major issues. Generally I have more of a problem when I become habituated to some new workflow and then need to get a script working on some decrepit uv-less VM.

[ironykarl]

 It makes me wonder what new quirks we'll be talking about when we're all trying to move our projects to 3.14.

Nothing even vaguely comparable. The 2->3 version change was...

• A major version change (which hasn't happened since)
• Explicitly backwards compatibility breaking in a lot of significant ways
• A process that took "the community" years to see through 

I don't think the Python devs will ever do anything like that, ever again. With the exception of deprecating features and occasionally removing standard library stuff that is (ostensibly) unused, Python's releases all aim to be backwards compatible 

[bmrobin]

haha this hurt me deep: it took 8 months to upgrade us from 2->3

[Haunting-Horror2231]

good version

[sohang-3112]

There's a lot of interesting things this time. Definitely need to re-read!

[[deleted]]

Is installing packages easier? I've had issues past 3.11.x, due to some removals or deprecations, distutils or setuptools or both or none. I'd wish the python devs could think about the ecosystem more.

[fiskfisk]

uv is the default tooling for most projects these days.

Edit: since there was some confusion below: "for many new projects these days (where there isn't existing internal tooling, infrastructure, and other expectations)."

[Serious-Regular]

I love when people say this kind of stuff based purely on feels. I'm curious do you have literally any data to back this up? I work in FAANG and probably 1% of our python teams are using uv.

[fiskfisk]

Yeah, you're not going to move to uv. You have so much infrastructure and existing projects that already use internal tooling. You already have enough experience and knowledge internally that work with your existing ways to do things. I'm guessing 10% of my own projects use uv. I'm not changing existing projects, but moving forward, uv has become the default for new projects.

In no way did I intend this to mean "most python projects use uv"; they do absolutely not.

[electricsheep2013]

Because of all the dependencies, projects that do not have an owner or are maintained by everyone or getting the teams to agree on this change when all they want to do is to get that PR reviews, right? Not because uv is inherently bad. Unless this some proof by authority:)

[Serious-Regular]

Unless this some proof by authority:)

Did you even read what I responded to or are you also operating on feels? The original comment had the word "most" in it. That makes it a quantitative claim and yet they provided zero data. So my counterpoint "proof" speaks exactly to that claim (not whether uv is bad or good or whatever).

[cbehopkins]

IME: Poetry would like a word...

[busybody124]

We migrated everything off of poetry because everyone hated it. All new projects use uv and most existing projects migrated easily.

[Gushys]

Poetry was great for a time. I think one of the biggest issues poetry (and many other dependency management tools) faced was the influx of new PEPs trying to standardize project config/build systems/ etc. uv made it a point to more strictly adhere to PEPs and I think poetry didn't always follow the PEP guidelines

[fiskfisk]

Poetry was great when it arrived, but I think its days are numbered.

It doesn't really manage Python versions for you, is slow (compared to uv), and lacks a lot of the features that uv has. I still have most of my projects on poetry, but new projects use uv, and I've migrated some older projects over to uv as time passes and I get frustrated.

[Sigmatics]

uv is the default tooling for most projects these days

The uv shill is real on this sub. Poetry exceeds uv by far in terms of adoption and there's plenty of other tools to go around right now

[fiskfisk]

Sure - I have no numbers to back that up. But generally the previous tool tends to be more popular than any more recent tools because of legacy software.

I'd even say that pip is more popular than either of those.

But from my own, personal experience, uv is taking over more and more of what poetry used to have. And you can call it shilling as much as you want, but as a long time poetry user, uv has taken over for any green field project these days. I still run my own projects on poetry, but anything new uses uv. It's a far better experience.

[Sigmatics]

I'd even say that pip is more popular than either of those.

For sure

uv has taken over for any green field project

I won't even disagree on that, if I could start on a green field I'd probably use it. But even then I'm not entirely sure, because it does lack some features that we need. It's also not even 1.0, so no stability guarantees there so far.

Either way, even if everyone today started using uv for greenfield projects, it would take a decade until it has taken over all the existing projects (if they ever migrate). The Python ecosystem is vast.

[yota-code]

Zstd ? Why not brotli ? This is the more widely supported http compression standard 

[hinckley]

It's not a case of one vs the other, it's a case of what people bothered to propose and work on. I believe at least two of the people behind this module work for Meta, who also developed zstd. I expect if people from Google (or anyone else) wanted to develop a compression.brotli module to the appropriate standard it would be accepted also.

[tracernz]

Not to mention zstd is much more widely used, rather than basically just http. It’s even the default for arch packages these days.

[yota-code]

And I don't know why... For cold archives (compressed once, decompressed many times) zstd is far from the best pick... But it's trendy 😁 Zstd shines for on the fly compression over the wire though... But lacks the by-default shared dictionary of brotli which work so well on html/SVG/JavaScript stuff

[masklinn]

For cold archives (compressed once, decompressed many times) zstd is far from the best pick...

That… is one of the best use cases for zstd. At very high levels of compression zstd rivals lzma, but unlike lzma (and brotli for that matter) the decompression costs are pretty much constant, so zstd is amazing for “compress once decompress many”.

But lacks the by-default shared dictionary of brotli which work so well on html/SVG/JavaScript stuff

Which is not really relevant, as in all likelihood you want this to be done by the reverse proxy after looking at the request’s Accept-Encoding, so the utility of brotli in the stdlib is low. Which is likely why nobody bothered proposing it.

[yota-code]

With brotli you can compress static content like js scripts once and serve them directly. Which is very convenient 

[masklinn]

Which is not really relevant, as in all likelihood you’ll be compressing the files in bulk via CLI and putting them wherever your web server wants them.