pjmlp
I really find a bummer that there is such a resistance to make JIT enable versions available for download, alongside the other variants.

Naturally I can easily compile my own Python 3.13 version, no biggie.

However from my experience, this makes many people that could potentially try it out and give feedback, don't care and rather wait.

MrThoughtful
Removing the GIL sounds like it will make typical Python programs slower and will introduce a lot of complexity?

What is the real world benefit we will get in return?

In the rare case where I need to max out more than one CPU core, I usually implement that by having the OS run multiple instances of my program and put a bit of parallelization logic into the program itself. Like in the mandelbrot example the author gives, I would simply tell each instance of the program which part of the image it will calculate.

bilsbie
This sounds silly but I’ve actually turned off garbage collection in short running, small memory programs and gotten a big speed boost.

I wonder if that’s something they could automate? I’m sure there are some weird risks with that. Maybe a small program ends up eating all your memory in some edge case?

pininja
I remember first discussions about removing the GIL back in 2021 and a lot of initial confusion about what the implications would be. This is a great summary if, like me, you weren’t satisfied with the initial explanations given at the time.
01HNNWZ0MV43FF
Oh it's like the rhyme "Jack and Jill went up the hill".

I spent all day not knowing whether "up the hill" meant they shipped or didn't ship. So they shipped, right? Or they shipped a JIT but removed the GIL?

sandos
So is it impossible to optimize the no-GIL case more really? 20% slower sounds like a lot really.
zahsdga
The performance degradation with nogil is quoted as 20%. It can easily be as much as 50%.

The JIT does not seem to help much. All in all a very disappointing release that may be a reflection of the social and corporate issues in CPython.

A couple of people have discovered that they can milk CPython by promising features, silencing those who are not 100% enthusiastic and then underdeliver. Marketing takes care of the rest.

nmstoker
Just a minor correction: it's looking like the release will be 7th October, back from 2nd October, for the reasons discussed here:

https://discuss.python.org/t/incremental-gc-and-pushing-back...

djoldman
Slightly off topic: does anyone have a link to recent work done toward automatic parallelization?

(Write single threaded code and have a compiler create multithreaded code)

https://en.m.wikipedia.org/wiki/Automatic_parallelization_to...

William_BB
Can someone explain this part:

> What happens if multiple threads try to access / edit the same object at the same time? Imagine one thread is trying to add to a dict while another is trying to read from it. There are two options here

Why not just ignore this fact, like C and C++? Worst case this is a datarace, best case the programmer either puts the lock or writes a thread safe dict themselves? What am I missing here?

bilsbie
I wonder if they could now add a way for the interpreter to automatically find instances where it could run your code in parallel?

You’d think certain patterns could be probably safe and the interpreter could take the initiative.

Is there a term for this concept?

debo_
What an incredible title.
v3ss0n
Experimentally JIT WHILE there is totally stable , 4-100x faster, almost 100% compatible PyPy exist and all they need is adopt it but didn't due to some politics.

Yeah right..

wruza
It’s worth mentioning that there is a bit more overhead in using multiple processes as opposed to multiple threads, in addition to it being more difficult to share data.

There’s probably a whole generation of programmers (if not two) who don’t know the feeling of shooting yourself in the foot with multithreading. You spend a month on a prototype, then some more to hack it all together for semi-real world situations, polish the edges, etc. And then it falls flat day 1 due to unexpected races. Not a bad thing on itself, transferrable experience is always valuable. And don’t worry, this one is. Enough ecos where it’s not “difficult to share data”.

kenzo123456789
[flagged]
kenzo123456789
[flagged]
mg74
The number one thing I wish was addressed in future version of Python is the semantically significant whitespace.

Python is absolutely the worst language to work in with respect to code formatters. In any other language I can write my code, pressing enter or skipping enter however I want, and then the auto formatter just fixes it and makes it look like normal code. But in python, a forgotten space or an extra space, and it just gives up.

It wouldn't even take much, just add a "end" keyword and the LSP's could just take care of the rest.

GIL and JIT are nice, but please give me end.

geor9e
is 3.13 bigger than 3.9
punnerud
The ones saying they will never use Python because it’s slow, is the probability high that their “fast” language is not thread safe?