Python 3.14 Released

Posted by chinawcswing@reddit | Python | View on Reddit | 106 comments

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

[-]

Username_RANDINT@reddit

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

[-]

chinawcswing@reddit (OP)

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

[-]

ganesh_k9@reddit

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@reddit

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

[-]

GoofAckYoorsElf@reddit

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

[-]

georgehank2nd@reddit

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

[-]

99ducks@reddit

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

[-]

jabbalaci@reddit

You chose a clever solution to still get the info.

[-]

SharkSymphony@reddit

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

[-]

champs@reddit

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

[-]

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@reddit

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@reddit

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)

[-]

snugar_i@reddit

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)

[-]

Brenan-Caro@reddit

3.14.1

3.14.15

3.14.159

[-]

anxxa@reddit

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. That's cool though, I didn't realize a JIT was being worked on.

[-]

georgehank2nd@reddit

~~Stage 3~~ Phase III might or might not happen.

[-]

MegaIng@reddit

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@reddit

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@reddit

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???

[-]

MegaIng@reddit

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

[-]

Local_Transition946@reddit

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

[-]

1minds3t@reddit

With omnipkg, locking and context swapping needs only 120ms to swap Py interps then run both concurrently. This is with minor optimizations too, I'm sure I can make it faster if I tried. so what is the issue with the current default cPyrhon builds?

[-]

james_pic@reddit

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.

[-]

HommeMusical@reddit

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.

[-]

Salamandar3500@reddit

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

[-]

anxxa@reddit

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.

I think based on the linked post + this it's suggesting that they're the same binary.

[-]

MegaIng@reddit

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.

[-]

Pristine-Hospital-19@reddit

Can I run all code with free-threading mode?

[-]

Excellent-Isopod-626@reddit

great I guess we got faster Python?

[-]

Embarrassed_Creme_46@reddit

No, we don't :(

[-]

Excellent-Isopod-626@reddit

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

[-]

Mskadu@reddit

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.

[-]

Tyler_Zoro@reddit

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.

[-]

its_a_gibibyte@reddit

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@reddit

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

[-]

MegaIng@reddit

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@reddit

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.

[-]

chat-lu@reddit

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

17 years ago. That was in 2008.

[-]

kenfar@reddit

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.

[-]

Tyler_Zoro@reddit

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. :-)

[-]

genman@reddit

Yes and I hate that you’re right.

[-]

vim_deezel@reddit

Gather round children! Perl was my first scripting language and held me for a while but it's so hard to back to scripts I wrote a year+ that I eventually gave up and moved on. Then someone at work found out I used to work a bit with Perl and I got a legacy Perl app dropped in my lap. It was a critical app, and quite large. It was miserable maintaining it, as feature requests came in all the time. I jumped ship after 5 years at the company after I warned my boss it was making me miserable and he wouldn't listen to me lol. Ended up in a better position anyway.

[-]

Tyler_Zoro@reddit

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.

[-]

vim_deezel@reddit

I think it's great for small scripts you can keep in your head after a couple passes, but once it crosses the line into a major app that is critical to an org, I want nothing to do with it :)

[-]

ShanSanear@reddit

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.

[-]

whatshldmyusernaymbe@reddit

So it’s now pithon?

[-]

BossOfTheGame@reddit

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')
"

[-]

chub79@reddit

Oh man, what a lovely addition!

[-]

HommeMusical@reddit

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

[-]

paperclipgrove@reddit

This feels like it was personal.

Congrats

[-]

AustinWitherspoon@reddit

That's great

[-]

alok-sha@reddit

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

[-]

Obliterative_hippo@reddit

Pi-thon has arrived!

[-]

Vyckes@reddit

I had to scroll to long to see this.

[-]

bobbster574@reddit

πthon

[-]

hleszek@reddit

π🐟 in French

[-]

syklemil@reddit

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

[-]

NN8G@reddit

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

[-]

ArtOfWarfare@reddit

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

[-]

Glathull@reddit

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

[-]

ArtOfWarfare@reddit

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

[-]

shinitakunai@reddit

Special cases are not spe ial e ough to break the rules.

Import this

[-]

greatslack@reddit

TeX has been doing that since the 90s

[-]

lukerm_zl@reddit

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

[-]

svefnugr@reddit

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

[-]

petter_s@reddit

90s? 70s!

[-]

danmickla@reddit

Because that would be stupid.

[-]

NN8G@reddit

Thank you for your attention to this matter.

[-]

OriginalOFace@reddit

π-thon

[-]

callmesun7@reddit

So it is piPy

[-]

DateSuccessful9440@reddit

The deferred evaluation of annotations is a nice QoL improvement that’s been a long time coming. I’m most curious about the practical use cases for the multiple interpreters in the standard library. Is the main benefit just better isolation for certain tasks, or are there specific performance gains people are seeing in testing? It seems like a powerful feature but I’m still figuring out where it would fit into a typical application stack.

[-]

Murder_Not_Muckduck@reddit

Pi-thon

[-]

Difficult_West_5126@reddit

Are we JIT yet?

[-]

LackingAGoodName@reddit

Finally

Pithon

[-]

flyingfox@reddit

Finally

Found the PEP 765 fan!

[-]

1minds3t@reddit

[-]

1minds3t@reddit

Python was already able to have multiple interpreters installed in a single environment, easily run code using each, and run them each concurrently in a single script. I have live github workflows running a script with 3.9, 3.10, and 3.11 concurrently with zero issues.

[-]

1minds3t@reddit

Wow, so they finally found out they could have had multiple interpreters installed and running in the same environment at the same time. Funny because I already solved this lol. ================================================================================ 📊 DETAILED TIMING BREAKDOWN ================================================================================ 🧵 Thread 1 (Python 3.9.23 | Rich 14.1.0) - Total: 354.9ms ├─ Prep (Lookup/Check): 44.3ms ├─ Wait for Lock: 0.9µs ├─ Swap Context: 68.9ms ├─ Install Package: 0.0µs └─ Test Execution: 241.6ms 🧵 Thread 2 (Python 3.10.13 | Rich 14.1.0) - Total: 426.8ms ├─ Prep (Lookup/Check): 45.3ms ├─ Wait for Lock: 67.9ms ├─ Swap Context: 65.9ms ├─ Install Package: 0.0µs └─ Test Execution: 247.7ms 🧵 Thread 3 (Python 3.11.13 | Rich 14.1.0) - Total: 464.4ms ├─ Prep (Lookup/Check): 46.5ms ├─ Wait for Lock: 132.2ms ├─ Swap Context: 43.5ms ├─ Install Package: 0.0µs └─ Test Execution: 242.2ms

[-]

vim_deezel@reddit

Ah Py PI

[-]

IlikeAlgebra@reddit

Pithon

[-]

Mr_Woodchuck314159@reddit

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.

[-]