Notes from the Meeting on Python GIL Removal Between Python Core and Sam Gross

I can't help but read all the interjections from the core developers as a strong indication of why all these sorts of things tend to fail on the vine. From Unladen Swallow onward there have been these groups off doing interesting and awesome experiments to try and make Python faster, and they never actually make it into something that Python end-users can use (yes, I know US had shortcomings). This is the work of one (admittedly super smart) guy over two years. Just like Nuitka, something else that was supposed to be impossible but just keeps making steady progress. Maybe I'm just seeing design by committee?

The lone geniuses can only go so far. Maybe the problem is that Python can't quite decide what it wants to be because it's too many things for too many people already.

Is the concept of Python the language, as opposed to Python the ecosystem, valuable enough so that a Python that broke backwards compatibility with all the C extensions would be useful as its own multicore-capable runtime? PyPy seemed to think so for a while and now has gone hard in the other direction, reimplementing (faking?) a bunch of the CPython extension API so maybe this approach would never work. I don't know, but seeing things like:

> there is a large number of “dark matter” Python (and C extension) code out there that isn’t open-source. We need to be careful not to break it since it might not be feasible for its users to make required changes, or to report problems back upstream to us. In particular, some C extensions protect their own internal state with the GIL. This is a big worry, and might be a big hindrance to adoption of a GIL-free Python.

really make me wonder if the community as a whole would conclude the same on these critical sorts of decisions which shape the future of the language if they were put forward and not just made by a couple people in a closed meeting.

Would you prefer to support some weird arbitrary nameless closed source extensions, or have a multicore Python? This obviously depends on who you are and what you're doing, which leads us back to Python being too much for too many, but even here we can get a feeling for how many people do what with the language.

I think there's a pretty good chance this stuff gets incorporated:

"On a personal level, we are impressed by Sam’s work so far and invited him to join the CPython project. I’m happy to report he is interested, and to help him ramp up to become a core developer, I will be mentoring him. Guido and Neil Schemenauer will help me review code for the interpreter bits I’m unfamiliar with."

Just came in here briefly to opine that there is a very real risk of fork if the Python core community does not at least offer a viable alternative expediently.

The economic pressures surrounding the benefits of gross’s changes will likely influence this more than any tears shed over subtle backwards incompatibility.

I believe it was Dropbox that famously released their own private internal Python build a while back and included some concurrency patches.

Many teams might go the route of working from Sam Gross’ work and if we see subtle changes in underlying runtime concurrency semantics or something else backwards incompatible that’s it- either that adoption will roll downhill to a new standard or Python core will have to answer with a suitable GIL-less alternative.

I for one do not want to think about “ANSI Python” runtimes or give the MSFTs etc of the world an opening to divide the user base.

These are exceptionally clear notes. They're easy to read and feel comprehensive. I also note that the author is the current CPython developer in residence (a recently created position).

I think Python core developers should not worry about closed-source enterprise Python code.

If users are gaining performance, they will bend over backward porting their code to this new version.

At minimum, I predict, all FAANGMULA would jumped in the bandwagon and create a pretty big ripple effect.

The site is currently past its hosting limit for the day.

https://archive.md/Zb8p2

(Archived through google cache, so two layers of cache.)

Suppose a Python module written in C registers a method that ends up making a call to C functions larry(), moe(), and then curly() to mutate a global variable "global_mutable_temp" before finally returning a value generated from global_mutable_temp.

1. Supposing this method doesn't currently crash under GIL python, would it be true that this method will also run without crashing on the non-GIL python interpreter?

2. Would it be true that the non-GIL python interpreter will introduce a race to this method (resulting in a runtime error) that didn't exist under the GIL interpreter?

Why is it never mentioned that Sam the lone genius Gross who is "interested in PyTorch training workflows" is a fulltime Facebook employee?

Not that it's bad but it should be mentioned that it's a corporate initiative.

I think switching the version to 4 is the most viable path. Make the last GILed python 3 an LTS release that interested parties can hold on to, eg. Ubuntu can keep python 3 as a default for a long time. One can always use conda to run multiple versions simultaneously.

Besides the internal politics, I think the greatest blocker with improving python performance is not giving whomever is running the code any control. If I don't use any naughty C plugins, or if I can assure you that I've annotated all my types and can allow a large class of optimizations, why can't I run my code with some VM flags?

It's one language, but why can't I tune my VM to my needs? I can't imagine Java not letting users tune their GC.

I wonder if a midpoint for this sort of work would be if a major distro or several declared they would move to GIL-free Python?

System python at least is generally only recommended to be used for system libs, and that's a relatively supportable set. Developers use virtualenv's and their own specific interpreter, but it would certainly move the needle on what language people were by default scripting and thinking in.

> What’s the level of perceived risk that the nogil project will end up not being viable for inclusion in CPython? (...)

> It all depends on how well the community adapts C extensions so they don’t cause downright crashes of the interpreter. Then, the remaining long tail is community adopting free threads in their applications in a way that is both correct and scales well. Those two are the biggest challenges but we have to be optimistic.

Even if it's 10% of the mess the path py2->py3 was, it still worries me. I hope I'm wrong and it's much less than that (for the fatal cases ATL, and similar/non improved perf for the rest)

It’s down, archive link: https://archive.md/Zb8p2

I remember that the python SQLite module is problematic because of the GIL. Would that solve that problem? What other sort of problem does it solve?

But on the other hand, isn't simple to just dedicate a script per core?

TLDR of my understanding:

What python commitee considered as infeasible was almost done by a lone hero. Since the previous decision to change the format of the print function (that no one asked for) broke everybody's code for no reason and took ten years to be adopted, they will not push (for the one change everyone wants) for the foreseable future. Although it does not seem to be that impossible after all.

I am glad they will invite Sam, the lone gero we needed and hope he will be given some ownership of the task and not get him swamped with commiteeisms through a embrace, not extend and extinguish. He is on a success path, the commitee is in no path at all.

Just put a timeline and call it a fail if don't succeed and quit avoiding it through "discussions". We got it, it's not planned for the X.XX+1 version, each version.

and here I am writing a CRUD app with flask :(

Impressive work (2 years working full time knowing that it might never be merged is incredible)

Python is used by a lot of "semi-technical" people (data scientists, researchers, hobbyists, etc). Removing the GIL isn't going to make their life any easier.