Hacker News Reader

Comment by qbasic_forever | Hacker News Reader

That's the exact attitude that lead to decades of pain with the 2 to 3 transition and libraries though. There was zero plan for how to help libraries migrate from python 2 to 3, or more importantly how does one library support _both_ python 2 and 3 from one codebase as their users take time to switch their python interpretor. The attitude of "just turn off GIL if you don't need it, just use libraries that support turning it off" means library authors will be asked to provide versions of their library that do and don't support non-GIL mode. That's a big burden to dump on library maintainers.

View on HN

I’m no fan of Java, but in comparison with python, Java’s focus on extreme backwards compatibility and their ability to actually execute on this promise year after year stands in stark relief with how python has handled the same challenges. I have low confidence, despite their claims this won’t be python 4, that this will actually be executed well. Looking forward to having homebrew deliver python@3.25_GIL and python@3.25_no_GIL with each flipping package I install.

Yep, and you'll have pip3-gil and pip3-nogil binaries because each permutation of python has separate and incompatible site-packages folders and libraries. It could get really ugly.

Lol the correct statement is it will get really ugly. Pretty much no question it will be a bigger mess than 2 to 3 transition. Here's hoping my subfield will move to a different language in the meanwhile because I don't want to deal with this shit again.

All your hopes of GIL free code ruined by a GIL requiring left pad dep buried deep in the dependency tree.

Fortunately Python’s package management is so horrible left pad is not a problem.

Is the situation in rust, where the answer is apparently to vendor the world, much better? Don't many of the big rust libraries still depend on nightly, too?

The major difference with rust is that the core language has strong backwards compatibility guarantees, and the package manager supports installing multiple versions of transitive dependencies so packages can be updated incrementally.

Right. GP was complaint about having a gazillion versions of every dependency sitting around to satisfy various whims.

> Don't many of the big rust libraries still depend on nightly, too?

No, none of them do, or at least none that I’ve ever seen in 4 years of doing rust full-time.

Or it could motivate total abandonment of system-level Python installations in favor of per-app virtualenvs or whatever the new hotness is, and we'll finally achieve world peace.

I can see system level python installs being abandoned. They seem to be getting progressively harder to use over time. I don't see the replacement being virtual env, it'll be a different language ecosystem. Whichever one looks like it has remembered "easy to do simple things in" is a feature.

While Python has never been my primary coding language, I've used it extensively for building scripts and tools, but I've pretty much given up on it. The language is so elegant, but the installation of it (with 2~3 compatibility issues being just a small part of that) just became such a turnoff. It's been super frustrating having to search the Internet every time I need to install something Python-related, to then find all sorts of conflicting instructions, bleh. Virtualenv, venv, a different Pip in Ubuntu, and so on. Since there's a lot of references to Java in these discussions: there's "sadly" two ways to do it: Maven and Gradle. That's still one too many, but at least not a new flavor du jour every year, like seemingly with Python.

And I'm sure someone will drive by, now, and tell us we have to use xyz, "obviously". But if that's not "obviously" what I find in an Internet search, then the community has apparently not agreed on it consistently in a sustained way.

The new official Scala build tool / compiler front end (scala-cli) is amazing,

https://scala-cli.virtuslab.org/

The thing that really struck me after years of python is how it lets you out dependencies directly in a comment on top of a script and it will download and run with them automatically, without poisoning any system settings. It's so simple!

> it lets you out dependencies directly in a comment on top of a script and it will download and run with them automatically, without poisoning any system settings

The old-style nix-shell command in Nix can do this[1] for every language and package Nixpkgs supports, although it’s not that often used because it ties your shebangs to Nix. (An equivalent feature for the new CLI is a work in progress[2].)

[1] https://nixos.org/manual/nix/stable/command-ref/nix-shell.ht...

[2] https://github.com/NixOS/nix/pull/5189

Just curious: what makes it "official"?

It's going to be rolled out as the new standard Scala repl and compiler (instead of the current scalac which is a bit weak on features.)

Having different build tools, that’s one thing. I can live with a somewhat wonky development environment to work on my code, as long as I can set it up once and it works after that. I would prefer elegance, just one is used and that’s it, but I don’t know of a language with a large user base that has that.

My point lies more in the install experiences for say, a command line tool written in said language. For Java I need one Java install on my system, it’s the most recent one. I install it and then all the old code just works, all my Java command line tools just work, I never have to watch homebrew install some stupid version of Java@11 when I have Java@13 installed like I do python@3.9 when I know I already have python@3.10. All of this is BECAUSE people basically threw up their hands and distribute the core language at their version with their code and their chosen dependencies “installed” into it… so we’ve all got 15 bespoke versions of the same language kicking around on our hard drives. That is really stupid.

When I learned Python decades or so ago virtualenvs were standard practice. Who is using system level Python for anything non-trivial?

I use Debian's system Python 3.10 install for most of my stuff and it works really well for me. Some things I install via pip but the key libraries (e.g. PyTorch) from source.

Don't you ever have projects with conflicting requirements? How about running stuff on a new box or after a reinstall?

I wonder if our definition of "non-trivial" might differ if neither of these apply.

I think this is standard and I find it a total and complete waste of my hard drive space.

As I understand it, as a library author you either do absolutely nothing and your library will be marked as requiring GIL by default. Nothing to do, you keep on working with that good old GIL and nothing changes.

Or you make the extra effort of being thread safe and you can declare your library as not requiring the GIL.

Now if a user script mixes your GIL free lib with an older lib that has not been updated, well, too bad for them. Even with your hard work, the code will still operate like before, everything gets the GIL treatment.

Normal python devs will need to track down which pesky dependency of their script is causing the GIL slowdown. Kinda sucks but at least nothing breaks.

It's a sensitive, opt-in, and safe way forward. Hard to argue against it, really..

Where can I read up on this planned way of working? This is not what the PEP says

It's in the "Py_mod_gil Slot" section [0] in the PEP:

> In --disable-gil builds, when loading an extension, CPython will check for a new PEP 489-style Py_mod_gil slot. If the slot is set to Py_mod_gil_not_used, then extension loading proceeds as normal. If the slot is not set, the interpreter pauses all threads and enables the GIL before continuing. Additionally, the interpreter will issue a visible warning naming the extension, that the GIL was enabled (and why) and the steps the user can take to override it.

[0] https://peps.python.org/pep-0703/#py-mod-gil-slot

Thanks. Glad to know now!

Here's what's puzzling me about this:

Why then is there even a need for a seperate nogil build? If it is like this says, wouldn't it be easier to just make the standard build switch to gil or nogil automatically (or honor the users choice).

The fact that the SC thinks having two versions suggests there is more complexity involved than this section of the PEP leads readers to believe.

You have to recompile your C extensions for the nogil build. Consider an application where one thread is calling xs.append from a C extension and another is calling xs.pop and xs[-1] on the same list object xs. In the nogil build these operations need to use a fine-grained lock on xs, and in the gil build these are thread-safe due to each thread holding the GIL when it does these operations.

On top of that, some of the list and dictionary operations are available to extensions as C macros to avoid the overhead of a C function call.

However, it looks like the nogil build will be able to run in "GIL mode" for maximum compatibility, including switching to GIL mode partway through execution, but I'm expecting this to be slower than running the gil build in GIL mode.

> However, it looks like the nogil build will be able to run in "GIL mode" for maximum compatibility, including switching to GIL mode partway through execution

Yes, that's what they were asking about. Why have two versions for a mode switch. Everything you explained before that is irrelevant, I'm afraid.

> but I'm expecting this to be slower than running the gil build in GIL mode.

That could be the answer to their question, but that's not definitive enough.

1. The "stable ABI" is broken on nogil, the selling point of the stable ABI was "add this C preprocessor flag and your extension will work on all future CPython versions, after paying a speed penalty". This is useful for eg closed source extensions. If the nogil build was the only build available, these extensions would require recompilation.

2. There are a lot of users that want fast Python and a lot of effort was put in to optimise it. I think the core team wouldn't want to release and expect everybody to use a version which regresses in performance, for a feature (nogil) which most won't be able to use due to using C extensions which haven't had nogil-supporting code changes.

> The "stable ABI" is broken on nogil, the selling point of the stable ABI was "add this C preprocessor flag and your extension will work on all future CPython versions, after paying a speed penalty". This is useful for eg closed source extensions. If the nogil build was the only build available, these extensions would require recompilation.

It looks for a flag, if it doesn't see it then it turns the GIL on.

Where is the need for recompilation?

> I think the core team wouldn't want to release and expect everybody to use a version which regresses in performance

But you're just guessing that it's slower in GIL mode, aren't you?

"Where is the need for recompilation?"

https://docs.python.org/3/c-api/typeobj.html#c.PyObject.ob_r...

The stable ABI lets extensions access the reference count of any object directly. I don't know why. Normally the functions Py_IncRef and Py_DecRef should be sufficient. Objects no longer have a single number as their reference count.

Edit: In Python 3.2-3.9, the stable ABI included Py_INCREF, the C macro.

https://docs.python.org/3/c-api/type.html#c.PyType_FromModul...

The stable ABI lets extensions create new Python types. These can override tp_alloc field to use custom memory allocators when instances of the type are instantiated. The custom memory allocator needs to initialise the reference count to 1.

> But you're just guessing that it's slower in GIL mode, aren't you?

There are new implementations with per-object locks of list.append, dict.__setitem__ etc. These are incredibly common operations in Python code. These inherently will be more complicated than the previous implementation, meaning more instructions and slower. So there needs to be a branch at the start of list.append of whether to go to the old gil implementation or the new nogil one. Adding a branch so frequently will inherently make the runtime slower.

Now with a lot of work these can be optimised and the speed penalty reduced, but CPython goes on an annual release cycle. If the nogil code is held as a fork of the CPython repository without being merged in, until it reaches a performance goal, that brings other issues.

> Objects no longer have a single number as their reference count.

Does that stay true once the GIL turns back on?

> These can override tp_alloc field to use custom memory allocators when instances of the type are instantiated. The custom memory allocator needs to initialise the reference count to 1.

I'm not following why this affects ABI compatibility, sorry.

> So there needs to be a branch at the start of list.append of whether to go to the old gil implementation or the new nogil one. Adding a branch so frequently will inherently make the runtime slower.

I don't know about that. CPUs handle always-taken and never-taken branches very well.

> Does that stay true once the GIL turns back on?

In the current nogil implementation, AFAICS, it seems the GIL can't be turned back on so there is no answer yet.

Theoretically, you could have a one-off operation which fixes all objects when the GIL is turned on. However, there's no way to get all objects in Python. gc.get_objects() only returns tracked objects, and there is no way to list untracked objects.

It seems, three fields are exposed on every CPython object in the stable ABI, any change which affects their offsets will break the stable ABI. https://github.com/capi-workgroup/problems/issues/4#issuecom...

> I'm not following why this affects ABI compatibility, sorry.

True, PyType_FromSpec can set tp_alloc to a wrapper function which papers over the difference in what the "allocfunc" should initialise the memory to.

Re performance - merging the change is the only way people will actually start targeting nogil.

> I don't know about that. CPUs handle always-taken and never-taken branches very well.

and dynamic patching is also an option.

I'm not sure if the stable ABI is really like... going to stick around. Python 3.11 deprecated numerous functions in it mostly around interpreter configuration (the new PyConfig and PyPreConfig APIs are by definition not ABI stable), and the last couple releases have shown that deprecations in Python do mean it'll be removed later. The question then is whether they'll drop these APIs with a 3.x release (which would break the entire preomise of the stable ABI) or during a bump to 4.x. It really ought to be the latter and I suspect Python 4.x is going to remove the entire notion of stable ABI.

In either case it seems obvious now that there is likely no point bothering with the stable ABI any more.

Because it's being prudent. With such a big project, the unknown unknowns are numerous.

Something nobody though about lurks in this nogil build, and we are only going to find out when it goes to prod and users report about it.

Instead of breaking the entire Python community's code, the risk is opt-in for a few years.

> how does one library support _both_ python 2 and 3 from one codebase

How does one library support both GIL and no-GIL?

Easy, it supports no-GIL, so it supports both. Done.

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.

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

I find it utterly confusing.

(*) 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.

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!

* removed comment as it was factually false *

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

no-GIL libs will work with the GIL on surely? So you won’t have to support both?

Where will you get no-GIL libraries, especially in the early days? Just yell at the maintainers of core libs like flask and requests until they use their volunteer and spare time to implement incredibly complex and tricky locking semantics all over their codebases, AND test it all with both GIL and non-GIL interpretors at scale to suss out race conditions? That just happens for free and overnight because a lot of people are plus one mashing on GitHub issues I guess?

Flask is pure python, isn't it?

Even pure python code could have race conditions with the GIL disabled. Stuff like accessing and modifying a dictionary item in python code is assumed and currently guaranteed to be atomic because of the GIL. Remove the GIL and decades of assumptions break.

I think that's a misconception? At least the way how I understood this issue.

Things like `map[k] = v` would be atomic both before and after nogil, and things like `map[k] += 1` are not atomic even with GIL, the read and store can be split from each other.

The GIL doesn't serialize the execution of threads, but ensures only one executes at a time. Therefore, the race condition issues you describe already exist even with the GIL. The GIL is only there to ensure that the interpreter doesn't corrupt Python objects and its internal data structures, which in the best case leads to a crash.

Come on, think about it harder. Do you really think this would even have a chance of becoming a PEP if python code was affected? If you thought even a little bit about it, then you would have come to the very simple conclusion "no" but here we are.

In Python, race conditions with the GIL will be race conditions without the GIL, and vice versa.

....I believe so.

E.g. there's no plan to make lists, dicts, thread unsafe.

But it's going to be much easier to demonstrate data consistency issues and bugs due to threading

If I understand correctly how the GIL works, the change will only affect libraries with native componentsml. Everything that's pure python will continue to work unchanged.

What exactly am I reading here? Requests and flask are both 100% python libraries. Do you take pleasure in trolling people?

Indeed. The burden is 2x at least. They already estimate it's going to take 5+ years, so that's 10x the cost of a current library. At least.

If the burden becomes too big, at some point people may find it is the easier option to switch to a different ecosystem. I hope not.

I hope it'll be lua. I fear it'll be javascript.

I hope it'll be Nim, I fear it'll be Julia.

Lua? Really?

That's by far the most unpleasant language I've coded in.

Lexical scope, first class functions, native coroutines, compiler available at runtime. Trivially extensible. It's semantically really close to lisp. Yep, lua's one of my favourites. The front end syntax isn't what I'd like but whatever, I can still see the AST through it with a little effort.

Obviously there are a LOT of languages you've never coded in.

Yes, I've never coded in brainfuck. But of the languages people actually use its been the most painful.

I am not using luajit for various reasons but the problem with the regular Lua interpreter is that the lua ffi backport from luajit is not included by default and the third party ones are broken on ARM.

Reply on news.ycombinator.com