You're saying, "just rewrite and re-release all your dependencies, it's easy!" which was exactly what happened disastrously with python 2 to 3.

You can down vote this til the cows come home but it’s historically what happened.

This “that’s not how it went” stuff going down is quite just blatant historical revisionism.

Maybe it’s a good idea? Maybe it’s not?

…but anyone down voting “this reminds me of the Python 2/3” fiasco has no idea what they’re talking about.

Except they're not at all analogous situations. In python 2 -> 3, if a new version of a library came out Python 3 only, you couldn't use both it, and your old Python 2 code at the same time. Here, you can use the GIL until every one of your dependencies have migrated, even as new versions of your dependencies come out with nogil support until one magical day they all have nogil and you can migrate. But since you have been able to keep up with the library and weren't just arbitrarily cut off at their last Python2/GIL version, it's not a huge breaking change!

I think this is misreading the PEP, but I am happy to learn otherwise.

If it was like you say there would be no need for the --nogil cli option. And there would be no need to have a discussion, at all, really. Python could just introduce the featuere and enable or disable the gil based on the packages installed and the highest threading mode possible.

Yet that is not what's planned as I read it.

> If it was like you say there would be no need for the --nogil cli option.

Testing the difference between running it with and without `nogil` without having to install 2 different interpreters.

Testing libraries during transitions.

Simply giving users a choice.

Convenience.

Almost no one uses pre-Go.1.11 (GOPATH instead of Modules) any more for project organisation, and the transition is trivially easy. And yet, the toolchain still reacts to `GO111MODULE=off`.

It's good if there's a benefit for everyone, like python 3 fixing the terrible Unicode story. It's not clear non-GIL will even be a net performance improvement for most people--you are effectively moving syncronization from the core runtime to each and every library and program at the edge. Writing safe code at that level doesn't come for free, your basic program will be slower (and likely buggier) if every call into a library is now doing its own little bespoke GIL instead of relying on python's global one like now.

I’m not gonna argue that point; but it seems massively disingenuous to down vote someone who complains “but now I have to rewrite my library because some people might use it in non-GIL mode”.

That’s not whining; it’s just an observation that the committee making these decisions gives zero ducks about the impact this will have for anyone other than the handful of vested parties involved in making the decisions.

Pypi has what, 500k projects on it? Many abandoned.

Whom exactly is going to update those?

Or do packages get an automatic “doesn’t work with no-GIL” unless the author explicitly opts to enable it?

Or do we live in a future where any package, with any dependency may or may not have undefined behaviour in no-GIL mode?

Like, sure… it’s a good change for many people… once all the hard work is done by the community.

Does that remind you of anything?

Mmm.

Yep I fully agree. It's going to ultimately mean 99% of people end up running in old GIL mode with deterministic behavior. Companies will get burned and have to have policies that absolutely under no circumstances will the GIL be disabled in their codebase. A very small handful of highly skilled and funded teams, probably at big companies only, will have the time and tenacity to make their code AND all their dependencies work in a miltithreaded environment without the GIL.

I work at a big company. We had probably millions of lines of Python. We migrated to c++ instead of to Python 3.

I'm really struggling to think of a scenario where that makes sense

I'm not convinced it's was the right choice either, but I'm not keen on Python, and not sold on Rust. Maybe Zig? I don't know. I personally like Typescript but even I will admit I'm not sure it's the best choice for a large, server-centric company.

At the end of the day,this is the very point the SC and core devs are ignoring in their decision.

They do recognize the impact on the ecosystem will be huge, they recognize there will be at least 5 years of parallel gil/nogil versions(*), and they say they don't want a 2-3 story all over again.

Yet they have decided against their own best advise (to avoid such a situation).

It utterly confuses me.

(*) not just one parallel version, there will be 2 for every release following the introduction. In reality organisations will have to maintain 4-6 different baselines of Python releases along with a matching (and likely differing) set of libraries. I don't mean to fearmonger, I just happen to maintain such environements and I know the effort that goes into this first hand.

They were put in an untenable situation, IMO. If they said no, there would be howls of protest, and a possible schism in the community, and the next SC elections could be an ugly competition between pro- and anti-GIL advocates. A "yes, but..." approach was about the only option.

First of all, these changes are not being introduced because of a committee. They are being introduced because a way to get true thread-based parallelism in Python has been one of THE top priority demands of a huge part of the Python developer community for ages.

> “but now I have to rewrite my library because some people might use it in non-GIL mode”.

Yes, if library maintainers want their library to remain relevant, they will need to accomodate what the languages developer community uses. This is true for all languages. If they don't want to, that's okay, the community will come up with new libraries.

> the committee making these decisions gives zero ducks about the impact this will have

If they were giving zero ducks, they wouldn't make it backwards compatible, nor would there be a command line option to control the behavior.

>Pypi has what, 500k projects on it? Many abandoned. > >Whom exactly is going to update those?

Languages that base decisions on the update behavior, or lack thereof, of library maintainers, effectively freeze themselves.

And why exactly is the update behavior of abandoned packages a problem? They are abandoned anyway.

> Like, sure… it’s a good change for many people… once all the hard work is done by the community.

The people who want to get rid of the GIL are part of the Python development community. Many of them are library developers themselves.

> They are being introduced because a way to get true thread-based parallelism in Python has been one of THE top priority demands of a huge part of the Python

Where is this demand exactly? We hear a lot of complaining but very often this is due to a lack of awareness of available (& often better) alternatives to threading.

There is a very small number of use cases that will benefit from free threading.

> Where is this demand exactly?

The motivation summary of PEP-703 contains some material on this:

https://peps.python.org/pep-0703/#motivation

Further discussions going back years can be found with a brief search. This discussion is almost as old as Python3.

> due to a lack of awareness of available (& often better) alternatives to threading.

Such as?

There are exactly 2: asyncio, which is useless for CPU/GPU bound workloads, and multiprocessing with all the pain of relying on expensive spawns, expensive and limited IPC and the joy of having to orchestrate across process boundaries.

Guess what the most common advice is for dealing with CPU bound parallelisation problems in Python? "Use another language". Guess what all the languages recommended (C, C++, Rust, Go, Java) have in common? They have thread-based parallelism.

> There is a very small number of use cases that will benefit from free threading.

Basically any workload that is CPU bound, which in the day and age of giant data aggragation and running huge ML models at scale is more important than every before, is a use case for this.

> Use another language

Right, because the whole point of Python is as a glue language for native libraries. Adding multi threading to Python is like adding to to Bash.

> Right, because the whole point of Python is as a glue language for native libraries.

I have had this precise need before. I have a multi-threaded native library. The multi-threading is essential for reasonable performance in the intended use-case for the library. But my users can't write C++ to call it; they'd like Python. They'd like to extend certain specific operations that my native library does during processing. I give them Python bindings. The perf gained by running the library on multiple cores is completely negated whenever multiple C++ threads of my native library need to run Python code.

> I’m not gonna argue that point; but it seems massively disingenuous to down vote someone who complains “but now I have to rewrite my library because some people might use it in non-GIL mode”.

1. But they don't "have to".

2. Even if they did, why would downvoting be "disingenuous"?

> Pypi has what, 500k projects on it? Many abandoned.

Most of them don't contain C extensions.

> Whom exactly is going to update those?

Its developers of course. Many are presumably watching PEP-703, others will require lobbying by their users. But there is no rush to do so because...

> Or do packages get an automatic “doesn’t work with no-GIL” unless the author explicitly opts to enable it?

> Or do we live in a future where any package, with any dependency may or may not have undefined behaviour in no-GIL mode?

... the interpreter will indeed fall back to enable the GIL if an extension is loaded that doesn't declare support of the no-GIL mode. Additionally, some extensions are actually safe to use without GIL as long as their Python APIs prevent concurrent access to them and thus act like the GIL themselves. In these cases, the interpreter can be forced to run without the GIL.

Isolating the C extension to another process is another possibility to reduce the impact on applications where all others can already run without the GIL. Actually, multiprocessing is already a common approach in the Python ecosystem for concurrent and parallel processing.

> Pypi has what, 500k projects on it? Many abandoned.

> Whom exactly is going to update those?

> once all the hard work is done by the community.

If I want to use Python with parallel threads in the app I'm building, I don't need to wait for every last one of those 500k packages. I can wait for only the packages I'm using, or risk it and force Python to run in nogil mode anyway. It's my choice.

> Or do packages get an automatic “doesn’t work with no-GIL” unless the author explicitly opts to enable it?

As other comments say in this thread: yes.

> Does that remind you of anything?

> Mmm.

2-to-3 burned you. We get it. You might be getting flashbacks to that nightmare. That is understandable. But you need to look beyond a surface level similarity — "That was a transition. This is a transition. They're identical!" — and at the actual transition itself. The problems of 2-to-3 aren't present here. The user is not forced to choose between two incompatible options. Library authors aren't forced to migrate their code forward. Users and library authors do not need to collectively choose one version over another. The newer version remains compatible with older code. The sky is not falling.

> every call into a library is now doing its own little bespoke GIL instead of relying on python's global one like now.

Is this some kind of joke? Do we live in clown world now? You do realize that a lock is a trivial primitive in multi threading?

The concept of a "little bespoke GIL" is ridiculous. A lock is a lock. Sure, an extension could just put a global lock on every extension call and then you do end up with an extension wide lock but every other extension remains unaffected. There is no intelligence or genius behind putting a global lock in the interpreter that somehow gets ruined by putting the lock in the extension. In fact, GIL is the dumbest decision you could make and everything from that point on can only get better, not worse.

It doesn't matter if this "happened historically".

Historically, Napoleon lost. That has zero impact on whether I get a promotion.

The 2 changes simply have nothing to do with each other. No-GIL python can still run GIL code, it just won't be able to run it in parallel.

"it supports both. Done." is not how Python 2/3 went. You have no idea what you're talking about.

No, I'm saying that the problem you worry about doesn't exist.

The problem -- as you point out -- with 2 -> 3 was that supporting both versions was very difficult. Because Python 2 couldn't run Python 3 code (and vice versa).

And thus libraries existed in awkward states for years.

But GIL can run no-GIL code. Supporting both is no harder than supporting one of those options (the no-GIL one).