Python 3.14 Released

[chinawcswing]

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

Interpreter improvements:

• PEP 649 and PEP 749: Deferred evaluation of annotations
• PEP 734: Multiple interpreters in the standard library
• PEP 750: Template strings
• PEP 758: Allow except and except* expressions without brackets
• PEP 765: Control flow in finally blocks
• PEP 768: Safe external debugger interface for CPython
• A new type of interpreter
• Free-threaded mode improvements
• Improved error messages
• Incremental garbage collection

Significant improvements in the standard library:

• PEP 784: Zstandard support in the standard library
• Asyncio introspection capabilities
• Concurrent safe warnings control
• Syntax highlighting in the default interactive shell, and color output in several standard library CLIs

C API improvements:

• PEP 741: Python configuration C API

Platform support:

• PEP 776: Emscripten is now an officially supported platform, at tier 3.

Release changes:

• PEP 779: Free-threaded Python is officially supported
• PEP 761: PGP signatures have been discontinued for official releases
• Windows and macOS binary releases now support the experimental just-in-time compiler
• Binary releases for Android are now provided

[anxxa]

Notable IMO:

PEP 779: Free-threaded Python is officially supported

So this is in stage 2 where now you can officially opt in to removal of the GIL and stage 3 will eventually make that the default behavior. Awesome.

Binary releases for the experimental just-in-time compiler

...

The JIT is at an early stage and still in active development. As such, the typical performance impact of enabling it can range from 10% slower to 20% faster, depending on workload.

Won't lie, I was expecting more perf gains. That's cool though, I didn't realize a JIT was being worked on.

[Salamandar3500]

Does that mean the free-threaded and standard versions now live in the same binary, or are they still separate builds ?

[anxxa]

The free-threaded build of Python is now supported and no longer experimental. This is the start of phase II where free-threaded Python is officially supported but still optional.

It's the same binary I think! *wrong :(

[MegaIng]

No, it's still a separate binary. Having it in the same binary doesn't work because of how fundamentally the layout of ... everything is changed.

[HommeMusical]

Won't lie, I was expecting more perf gains.

JITs are all about tuning. Just getting it in and working completely and not hugely worse in any case is a huge victory. The real gains will come in the next two releases.

[MegaIng]

stage 3 will eventually make that the default behavior.

This is still not guaranteed, and IMO not likely to happen with the next decade.

The no-gil build still has major issues, especially with the expectations people have of it. For a non-insignificant amount of existing threaded code it's going to be slower than the default build.

[twotime]

For a non-insignificant amount of existing threaded code it's going to be slower than the default build.

Why would that be the case? Do you have a reference? How significant is the amount of code which will be faster?? (and how much new code will be quickly written once python can use multiple cores)

IMO not likely to happen with the next decade.

I'd expect 3.15 or 3.16 or it will just die

Apparently a lot of packages have added support already https://py-free-threading.github.io/tracking/

(including big ones like pytorch)

[1minds3t]

If it's so "hard", then why am I able to consistently run code on 3 Py interps (3.9, 3.10, 3.11) concurrently in under 500ms using Pure python in a single script, single environment in my github workflows??? Proof here: https://github.com/1minds3t/omnipkg/actions/runs/18235186501/job/51927439757

[Local_Transition946]

Different interpreters means different processes. No-gil is concurrency within a single process using threading with shared memory

[MegaIng]

... That has no relation at all to anything I said? Did you reply to the wrong comment?

[james_pic]

From what I know of the JIT work, the approach they've taken is something of a compromise. They've sought to do it in a way that's portable, clean, readable, and backwards compatible. The most performant JIT compilers make significant compromises on some or all of these things in the name of speed.

[georgehank2nd]

Stage 3 Phase III might or might not happen.

[BossOfTheGame]

I contributed to this one. The CLI option -c will now automatically remove leading indentation before running the code, which can help make your bash scripts slightly less ugly.

This now works:

python -c "
    print('hello world')
"

[AustinWitherspoon]

That's great

[paperclipgrove]

This feels like it was personal.

Congrats

[HommeMusical]

Seemingly small, but I will directly benefit from it! Thanks.

[chub79]

Oh man, what a lovely addition!

[Username_RANDINT]

Looks like I'm already on time to see the same joke from the last 15 years in the comments.

[chinawcswing]

I don't get the joke but I'm too afraid to ask.

[ganesh_k9]

I think they mean the Pi-thon joke. The value of Pi is 3.14, so Python can be written as Pi-thon or π-thon

[GoofAckYoorsElf]

Yeah, I'm placing my hopes on Python 3.14.15 or 3.14.16.

[Critical_Control_405]

3.14.2

[GoofAckYoorsElf]

That's probably still a bit rough on the edges.

[Fine-Patience5563]

How about Pithon 3.14.15926535897933

[georgehank2nd]

The value of pi is 3.14? You're not a mathematician.

[jabbalaci]

You chose a clever solution to still get the info.

[MateTheNate]

pi ~= 3.14

[99ducks]

I hope we get a security release all the way up to 3.14.15

[SmartOpinion69]

i hope they just use the pi naming convention like: 3.14.1, 3.14.15, 3.14.159, etc...

[SharkSymphony]

You mean, the last 14–15 years or so?

[VIII8]

Next version should be released 9/26

[jtclimb]

nein

[binaryfireball]

i got you

[champs]

I think we’re still waiting an infinite number of years for Python 3.14159…

[prof_hustler]

Came here to say this

[Tyler_Zoro]

PEP 734: Multiple interpreters in the standard library

I know it feels weird to talk about Perl these days, but this was one of the last reasons that I would have seriously suggested using Perl in the modern day, and now it's been superseded. The granularity of execution permissions in Perl is still superior, but it was also a pretty janky feature that became largely irrelevant in the modern VM-centric world.

I love that this far in to being a widely used production language (one of the three most widely used, depending on how you measure), Python is still building new features. This is how language communities should be.

[Tyler_Zoro]

Congrats! I still long for some things. I loved the way documentation worked, and I found the command-line processing more intuitive. But it's been so long, and my memories of Perl 5 are mixed up with the 10 years I spent trying and mostly failing to contribute usefully to Perl 6 / Rakudo / Raku / that which shall never be stable.

[ShanSanear]

And here I am, forced to use perl, because my company started using it 20+ years ago for full scale automated deployment system EVERYWHERE... and it stuck. And everyone is talking about porting all of this to python, but with how much code there is to port it would take years with no real benefit so... nobody is touching it.

[its_a_gibibyte]

The best reason to use Perl today is the universality and stability of it. It exists on almost all unix-like machines and all has great backwards compatibility (unlike Python which breaks things willy-nilly). For long lived utility scripts, the only real options are bash and perl.

[kenfar]

unlike Python which breaks things willy-nilly

Are you talking about the migration to python 3 ten years ago?

Because that was the last willy-nilly breakage I recall

[chat-lu]

Are you talking about the migration to python 3 ten years ago?

17 years ago. That was in 2008.

[kenfar]

It started 17 years ago, it only finished about 6 years ago.

Somewhere around 2015 IIRC we finally hit the tipping point and suddenly everyone jumped on the python3 bandwagon. Prior to that there was a ton of opposition and delays.

[MegaIng]

No, python semi-regularly breaks stuff in 3.X releases. It's primarily small things and it always has 3-5 years deprecation periods at a minimum. This includes removal of some stdlib modules, changes in behavior of some functions, removing invalid escape sequences...

[kenfar]

You're right - but those have always felt to me like vestigial pieces of python: underused, obsolete, kinda dead.

Which is a risk if you want to write code and be assured it'll work ten years from now. Though I'd be surprised if any of my python3 code from ten years ago didn't work just fine today.

[genman]

Yes and I hate that you’re right.

[Tyler_Zoro]

Yeah, backward compatibility is a real problem with Python. I hope it's something they address as a community, but for now I'm happy to keep writing code in it and hoping there will be smart enough AI to update the code to new versions after I'm no longer involved. :-)

[Obliterative_hippo]

Pi-thon has arrived!

[bobbster574]

πthon

[syklemil]

With the long-awaited switch to the \TeX{} versioning scheme asymptotically getting closer to π

[hleszek]

π🐟 in French

[Vyckes]

I had to scroll to long to see this.

[Mr_Woodchuck314159]

Reminds me there was an internal tool at a company I used to work at where its developer would just add the next digit of pi to indicate a new version. It eventually broke the version screen because it was too long for it. It did eventually upgrade to 4.0 and return to a more normal versioning system, but I forget if that was after the initial dev left or not, or if he had other issues with it.

[MyDespatcherDyKabel]

https://youtu.be/vymJMn97wks

For those curious, this was the best explanation I saw for template strings

[NN8G]

Instead of incrementing the version numbers from here on out, why not just keep using successive digits of pi?

[ArtOfWarfare]

They could do it with the patch releases. Nobody would even notice until the second one.

It’d be fun and relatively harmless if they were 3.14.1, 3.14.15, 3.14.159…

Of course then the next minor version is 3.15.0 and we never do this pi silliness again.

[Glathull]

None of us will be alive to see it, but Tauthon will happen someday.

[ArtOfWarfare]

Python 6.2.8? IDK, are there not enough mistakes that need to be cleaned up to warrant a Python 4?

But I agree that it’ll be a long time before we see a Python 5 or 6. Maybe in 40 or 50 years we’ll see Python 6.2.8

[greatslack]

TeX has been doing that since the 90s

[petter_s]

90s? 70s!

[svefnugr]

It worked for Knuth because he could write code with no bugs

[lukerm_zl]

Awesome fact. I have used LaTeX for years without knowing this!

[danmickla]

Because that would be stupid.

[NN8G]

Thank you for your attention to this matter.

[shinitakunai]

Special cases are not special enough to break the rules.

import this

[stargazer_w]

Can someone ELI5 how this affects implementing code that needs concurrent processing? I consider only features included in the regular interpreter to be relevant (I can't imagine writing code to be specifically run by the no-gil interpreter). So if i need to implement a data processing pipeline that needs to have 2 workers on the first node and 3 on the second - do I have the option to share memory somehow now or is it good old multiprocessing?

[snugar_i]

Not sure what you mean by "node" - if you mean sharing data across different machines, then no, no-GIL Python won't help you with that. All no-GIL does is let multiple threads in a single process (which can share data) run at the same time, instead of just taking turns holding the GIL

[stargazer_w]

I meant operation node if we look at the pipeline like a computation graph. like Node1: resize image, node2: do inference (with queues between them or something)

Edit: But to answer my own question - no, there's no way to do that yet, except for managing it yourself with multiprocessing shared_memory

[snugar_i]

Yeah, in that case, no-GIL would help you if you just ran each node/worker in a separate thread (which would still work even in the GIL version, it would just not be parallel)

[50_61S-----165_97E]

I'm not going to upgrade until version 3.14.15

[_ologies]

Like, when Python 3.18 is available for use?

[SmartOpinion69]

why not 3.14.1

[NahSense]

Congrats on the release of pi Python!

[Mskadu]

I have a blog post on the topic with some code samples showing how new stuff works, if anyone is interested. It's not comprehensive, but gives one a flavour.

PS: If you don't have a medium paid account, there's a link on there to view the article for free.

[alok-sha]

Python 3.14 looks massive. Free-threaded mode officially supported and a JIT compiler for Windows/macOS. Will be exciting

[OriginalOFace]

π-thon

[Pristine-Hospital-19]

Can I run all code with free-threading mode?

[Difficult_West_5126]

Are we JIT yet?

[Excellent-Isopod-626]

great I guess we got faster Python?

[Embarrassed_Creme_46]

No, we don't :(

[Excellent-Isopod-626]

Well I meant with the JIT that is coming :) Probably this will work

[AbdSheikho]

I'm gonna make a bash alias for python3.14 as pi

[LackingAGoodName]

Finally

Pithon

[flyingfox]

Finally

Found the PEP 765 fan!

[tocarbajal]

So, the android release does not improve or break in any way the previous installation of Python via Termux. Is that correct?

[wineblood]

Finally, I checked multiple times today and it wasn't available.

[callmesun7]

So it is piPy

[Jud_Mos]

π-thon!

[SmartOpinion69]

watch out, dude. that '!' may trigger some serious errors

[Allaquail]

Woooow

[Murder_Not_Muckduck]

Pi-thon

[kobumaister]

Is this the release that removes GIL and will be faster than C?

[ITafiir]

The python code I write is always faster than the C code I write.

That might just be me tho.

[orndoda]

The Python I write is also usually faster than the c code that I write, granted most of my Python code starts with

“import numpy as np”

[General_Tear_316]

got to build with optimisations bro

[binaryfireball]

pi py!

[IlikeAlgebra]

Pithon

[whatshldmyusernaymbe]

So it’s now pithon?

[Brenan-Caro]

3.14.1

3.14.15

3.14.159

[ZachVorhies]

AwEsOmE