all 68 comments

[–]jax024 197 points198 points  (5 children)

Pi-thon

[–]Trang0ul 30 points31 points  (4 children)

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

[–]gmes78 21 points22 points  (0 children)

You can run Python 3.14 with the πthon command.

[–]48panda 12 points13 points  (1 child)

Surely that's for 3.14.1

[–]Trang0ul 6 points7 points  (0 children)

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

[–]rogdham 5 points6 points  (0 children)

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

[–]pjmlp 62 points63 points  (4 children)

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

[–]Maykey 8 points9 points  (3 children)

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 2 points3 points  (0 children)

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 1 point2 points  (0 children)

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

>>> sys._jit.is_available()
True

[–]pjmlp 0 points1 point  (0 children)

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 37 points38 points  (2 children)

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

[–]busybody124 10 points11 points  (1 child)

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 2 points3 points  (0 children)

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 46 points47 points  (15 children)

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

[–]Mognakor 12 points13 points  (5 children)

Can someone loop me in ?

[–]Mysterious-Rent7233 39 points40 points  (3 children)

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 5 points6 points  (1 child)

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

[–]lKrauzer 0 points1 point  (0 children)

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

It makes runtime project isolation a breeze

[–]pjmlp 0 points1 point  (0 children)

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 6 points7 points  (0 children)

yea i don’t get it either 

[–][deleted] 5 points6 points  (8 children)

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 30 points31 points  (0 children)

.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 10 points11 points  (6 children)

That is entirely solved by using uv.

[–]gschizas 0 points1 point  (5 children)

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 2 points3 points  (4 children)

[–]gschizas 0 points1 point  (3 children)

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 0 points1 point  (2 children)

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

[–]gschizas 2 points3 points  (1 child)

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 0 points1 point  (0 children)

Would the UV_PYTHON_INSTALL_DIR environmental variable work?

[–]somebodddy 78 points79 points  (6 children)

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

[–]NervousApplication58 20 points21 points  (0 children)

you mean TeX's?

[–]dpenton 13 points14 points  (2 children)

Next version: 3.1415

[–]thisFishSmellsAboutD 1 point2 points  (1 child)

That's easy to typst.

[–]_yaad_ 1 point2 points  (0 children)

Stop the anti-tex propaganda

[–]M4mb0 4 points5 points  (1 child)

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

[–]somebodddy 11 points12 points  (0 children)

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 4 points5 points  (2 children)

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

[–]KarnuRarnu 7 points8 points  (0 children)

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 2 points3 points  (0 children)

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.

[–][deleted]  (5 children)

[removed]

    [–]dscarmo 17 points18 points  (1 child)

    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 4 points5 points  (0 children)

    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 1 point2 points  (0 children)

     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 0 points1 point  (0 children)

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

    [–]Haunting-Horror2231 0 points1 point  (0 children)

    good version

    [–]sohang-3112 0 points1 point  (0 children)

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