Hacker News Reader

Comment by ggm | Hacker News Reader

Lots of C library code for decades carried man page warnings it was unstable for use in async, re-entrant and recursive contexts. We learned how to cope and incrementally re-entrant safe versions deployed without too much API instability. Maybe time has healed wounds and caused me memory loss of the pain of discovery you'd tripped over them.

String parsing which tokenised in-place. DNS calls which used static buffers. Things which exploited Vax specific stack behaviour.

I think the GIL has been a blessing and a curse.

View on HN

I remember scouring those C runtime docs, for every non-reentrant function. It might be what got me in the habit of checking docs when using some API that I know moderately well, just in case there's some important detail I missed before, or something had changed.

Around that time, doing cross-platform C++, I got an early look at Java, with concurrency built in from the start, along with GC and various other nice features that were easier to use than C++, and I "knew" it was going to be huge. (But who knew that the MIS people would take over Java, when it seemed clearly targeted at non-MIS programmers, and now MIS people are stuck with the C++ syntax and verbosity, after coming from 4GLs, etc.)

Then mainstream programmers picked up Python, which, IIRC, originally was an embeddable extension language, which was why it was simple. And for which the GIL made more sense.

> I got an early look at Java, with concurrency built in from the start, [...] and I "knew" it was going to be huge.

And Java doesn't even have good (conceptual) support for concurrency. Compared with eg Erlang, Rust or even Haskell.

But Java was still better at it than C or C++ at the time.

In your opinion. Some of us believe the exact opposite.

There are a lot of good things about java (and the jvm by some extend), but good concurency is not one of them.

This is not true. JSR-133 was one of the first and most prominent implementation of memory model among general purpose languages. You don't seem to know enough about the platform and it's history to make definite statements like that, imo.

JSR-133 was quite a few years after Java's release. But even after these changes, many problems remained. For example, standard library classes were often not thread safe out-of-the-box, even something seemingly innocuous like a date formatter class would malfunction in a threaded context. The rules around thread safety were also very complex, especially with regard to constructing objects. IMHO, it did not compare well with other languages around the same time built with concurrency in mind, for example Erlang. I was once very fortunate to meet Joe Armstrong and we briefly discussed Java, suffice to say he was not impressed by it.

By exact opposite you mean that when Java just came out ('I got an early look at Java, [...]') had good concurrency support?

One can make a solid argument that modern Java is adequate. But I don't buy you believe that of early Java?

Old mate isn't alone.

I agree that Rust handles concurrency about as well as Java (in addition to its memory safety). But could you provide docs on Erlang or Haskell concurrent data structures that were better than Java’s, say, 10-20 years ago? Java’s support for concurrent data structures was pretty unprecedented in its heyday.

STM, 2006? https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.67...

Still way after Java was released I guess

Java didn't initially ship with lock-free data structures, those came later thanks to Doug Lea.

The best example of this is probably the “Beautiful Concurrency” paper from Simon Peyton-Jones in 2007 https://www.microsoft.com/en-us/research/wp-content/uploads/...

Compared to those other languages, Java has no mechanism to enfore the use of concurrent data structures, it's entirely up to the programmer to use them.

Java still doesn't provide persistent data structures out-of-the-box. IMHO these are more important than lock-free mutable data structures.

When one really does need shared mutable state, Haskell supports transactional updates to mutable state (STM), with optimistic locking and rollbacks. It's awesome, but unfortunately just not practically possible in any language with rampant untracked side-effects.

Erlang processes are a first class object. Data is immutable. There's a special syntax for sending and receiving messages between processes.

I would say that in some ways this is simply incomparable to java but I think this concurrency model is probably the easiest and simplest to work with of any concurrency model.

There are obviously drawbacks like with anything but for a lot of situations it's an excellent choice.

> But Java was still better at it than C or C++ at the time.

That's not even a contest. Java was released in 1995. At that time C did not have any kind of support for concurrency, all solutions were platform dependend and not part of the language.

> I remember scouring those C runtime docs, for every non-reentrant function.

hint:

  % cd /usr/include
  % ag --no-color '[^A-Z]_REENTRANT'

What are 'MIS people'?

Management Information Systems, I think.

I do so love playing guessing games for every comment I read.

I don't think it's reasonable to expect people here to cater to a least common denominator of comprehension.

Nothing “least common denominator of comprehension” about not knowing what that acronym means. I also didn’t know.

That's fine. But, communication is a skill and like all skills, can be improved. For my part, this is the first time I can remember seeing MIS used in the wild (i.e., not in university). Given the tech industry's propensity for overloading initialisms and redefining terms, I have to go by context to work out the meaning. In this case, the context was insufficient.

I suppose I could just dismiss the comment, but curiosity got the better part of me. I'm glad someone asked. I also had to search what "4GL" means. I'm assuming this top Wikipedia hit [1] is what the OP meant.

I don't know if it's reasonable to expect people to know these terms. But, the concise text is not saving anyone beyond the OP any appreciable amount of time, so what's its value?

[1] https://en.m.wikipedia.org/wiki/Fourth-generation_programmin...

Speaking of which I never fully understand the meaning of OP. It seems there’s a few semantic ranges there and people sometimes use OP standing for slightly different things.

Yes but unless I'm a extreme outlier "MIS" is not part of the common denominator.

> originally was an embeddable extension language

Python was originally a teaching language, to replace BASIC and Pascal for kids and beginners.

(Yes, there once was a time when people took teaching programming seriously.)

Quoting from [1], section "The ABC Project"

> The letter “B” was chosen because it is the first letter of the word “beginner” and because the project was meant to become a language for teaching programming to absolute beginners.

[1] https://inference-review.com/article/the-origins-of-python

Python was not originally a teaching language.

Yes, van Rossum was an implementer of ABC, which was a teaching language. Python drew on that experience, but also from Modula-2 and Modula-3, and the needs for writing an extension language for the Amoeba operating system.

From the initial release notes at https://www.tuhs.org/Usenet/alt.sources/1991-February/001749... :

  [Python is] an extensible interpreted programming language that
  combines remarkable power with very clear syntax.
  
  This is version 0.9 (the first beta release), patchlevel 1.
  
  Python can be used instead of shell, Awk or Perl scripts, to write
  prototypes of real applications, or as an extension language of large
  systems, you name it.

No mention of it being a teaching language.

That Java had concurrency built in from the start is a blessing mostly, but also a bit of a curse. Most of the Java ecosystem is still in the mindset that threads are cheap and firing up a couple more cannot hurt. So we end up with apps that run thousands of threads and this disease is hard to contain.

Like not everyone toy app isn't going to be the next FAANG, there are plenty of workloads where it hardly matters, while 30 years later it is still a mess in C and C++.

And between C++ and Rust coroutines, still not sure which one I like less.

I thought so too until I got to interact with databases and Big Data tools written in Java. God, what a mess that requires so much upkeeping, more dependency problems than I remember from C++ and probably some orders of magnitude more resources than they should.

Doing code review for C++ code delivered by most well know offshoring companies, versus what they deliver in Java, will help get another point of view.

Thankfully LLMs are becoming a viable, cost-effective, option for stuffing your favorite offshored codebase with even more unmaintainable spaghetti. What a time to be alive.

"And between C++ and Rust coroutines, still not sure which one I like less."

I, myself, am not a Go guy, but I feel it has to be mentioned here. Go's approach might not be as universal as C++'s or Rust's but I think for a large number of use cases it makes sense.

Many that praise async/await in C#, kind of forget it took about 10 years to spread across all the layer of the language and runtime, since it was done via IL rewriting, it caused several issues with F# async tasks, due to the age of the ecosystem plenty of code isn't async/await friendly and needs to be wrapped into Task.Run() or similar.

There is a best practices guideline from one of the ASP.NET architects, https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/b...

During last year they researched adding Go/Java's approach to .NET, but now it is too late. See the ASP.NET Q&A session at BUILD 2023.

This seems to be the relevant part of the Q&A: https://youtu.be/H5jI76Fq420?t=2396

Aside from being too late (already having two models and not wanting to add a third) they also mention that the Go/Java approach adds a performance penalty when calling native APIs.

Fortunately Virtual Threads have landed, so when the ecosystem finally comes around to adopt it, many things might become faster.

Threads are cheap compared to the process-per-request model that came before. And they're easy to code for, you don't have to worry about blocking code or awaiting your futures in the correct way or things like that. They're not optimal if you want to squeeze lots of concurrent requests into some memory-limited box. But on the other hand even dumb threading offers more throughput than python or node.

Green threads are coming to Java this September so all this will be moot.

I wish, but I'm skeptical. It's not that we don't already have the means to be reasonable with threads. The issue in my opinion is more a mixture of path dependency and a mindset that changes too slowly.

Python has many similar restrictions even in the language itself, they just tend to be exceptionally poorly documented.

For example, you can't safely use print in a Python signal handler, because the entire I/O system is not reentrant [1], yet the documentation shows doing this in a "how to do it properly" example [2] while explaining that it's horribly unsafe to throw from a signal handler, which is the default for SIGINT. (And also the reason why the threading module doesn't expose PyThreadState_SetAsyncExc). So despite appearances to the contrary (since the Python signal handler is invoked by the VM, it doesn't actually run in a signal handler context; the signal module registers a C handler which simply sets a flag that is checked by the VM every instruction), you should probably only do in a Python signal handler what you would do in C, which is very little. Set a flag or write to a pipe. Don't go around and call library functions.

[1] E.g. https://bugs.python.org/issue24283 [2] https://docs.python.org/3/library/signal.html#note-on-signal...

No-GIL mode is optional, and libraries will be marked "no-GIL compatible" and the ecosystem will gradually support more and more of these.

No one's flipping a switch and breaking mountains of sketchy C.

Well someone has to say it so I might as well: Is this going to be another Python 2 -> 3 cat herding exercise again?

I suppose the need to run your app in "no-GIL" mode is less than needing to jump from 2.7 to 3.

I didn't dive deep on this, but I assume that GIL mode can still run anything, including no-GIL code (it is one of their promises, at least). So, unlike 2->3, there is forwards-compatibility.

It also seems like the latter isn't meant as a replacement (for the moment), but rather as an option.

Presumably C extensions will have a different API name/ABI to prevent accidentally calling into GIL code when in non-GIL mode and vice/versa so that's going to complicate the compatibility story.

  stat = rt_oldFunctionName(&newStateArg, oldarg[,...])

mostly (again from memory. I'd not live or die by this)

As sibling comments says, GIL mode can run no-GIL code.

Entirely different from 2->3.

That analogy is so poorly applicable it's laughable.

Without the last sentence, your comment would be better.

It's not nice but it is true.

"Dur dur this <insert anything here> is just like 2 -> 3."

HN had always been susceptible to drive-by ignorant comments, but it's reaching new levels.

There's literally nothing of substance to the suggestion. (And if you think there is, present an actual informed argument.)

It wasn't a suggestion, they were asking a question.

Oh please. Even if we ignore that any question can have implications, they directly said "someone has to say it".

They were explicitly suggesting something by asking that question.

They were suggesting that this is a question that is going to be on people's minds, which is very different from suggesting that the answer is yes.

All I can say is that the phrasing looks quite biased to me and it would have been easy to not phrase it that way.

Subtext is hard to prove, but that doesn't make it not real.

It seems to have clearly been a case of "I remember 2 to 3, that was really bad. I imagine everyone else is wondering this - is this going to be another 2 to 3?"

I sympathise with you, I'm a little tired of these same recycled comments every time the Python comes up.

GP would probably be better if they didn't default to snark / derision by calling it cat hearding.

But the python 2->3 migration has been exactly that

No cats were harmed in the migration from Python 2 to 3.

Programmers and project managers on the other hand...

I would hope they're not hurting the cats that they're herding. That's pretty terrible shepherding

From the article:

> We want to be very careful with backward compatibility. We do not want another Python 3 situation …

I hope you are right. I fear it will turn out rather painful (I have lived through 10 years of Java multithreading, I don't miss it)

* update: I have also lived through 10 years of Python 2-3. It was not pretty.

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.

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.

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

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.

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?

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.

> marked "no-GIL compatible"

Ugh, Nomenclature is hard

Because non-GIL compatible doesn't mean GIL incompatible

"requires GIL" for all current projects?

Coming from a place of total ignorance, it would be nice if you could do this more incrementally, like have it be in no-gil mode by default, but then have a context manager you can use for gil sections, and have the interpreter bomb out if you try to enter gil-required code while still in no-gil mode.

The issue is when someone's unattended-upgrades bumps up the version and causes something to come crashing down. The people who need to use nogil should know that they need to, and will now have the ability to enable it

Almost more importantly, it is also possible to force the GIL to remain on with `PYTHONGIL=1`

> ... unattended-upgrades bumps up the version

Surely, unattended-upgrades should NOT be bumping major versions?

> No-GIL mode is optional

Long term the plan is to 100% remove the GIL from python.

From the article:

> Long-term, we want no-GIL to be the default, and to remove any vestiges of the GIL (without unnecessarily breaking backward compatibility). We don’t want to wait too long with this, because having two common build modes may be a heavy burden on the community (as, for example, it can double test resources and debugging scenarios), but we can’t rush it either. We think it may take as much as five years to get to this stage.

Under base assumptions it also says:

> We want to be very careful with backward compatibility. We do not want another Python 3 situation, so any changes in third-party code needed to accommodate no-GIL builds should just work in with-GIL builds (although backward compatibility with older Python versions will still need to be addressed).

That can't stay forever.

We're now up to 128 core CPUs, and even cheap CPUs have 6 cores on them. Restricting things to a single core's performance gets more and more limiting as time passes.

I remember these warnings as well from when I started programming C seriously in the 90s. When I first encountered them I was convinced these issues will be resolved in a matter of weeks, maybe a couple of month at worst. Ohh, so little did I know.

I have a hard time seeing the equivalence here. In C the interaction with non thread safe functions is much more direct. Most people are also more cautious when writing in C.

In Python you have whole C modules with global state. Load 10 of them, add the interpreter complexity and soon enough no one knows what is going on any more.

As it is, most developers (including core devs!) don't even bother to check for memory leaks. I don't think they'll run tsan, and if they do, it will be on a small test suite that only covers 10% of the code.

Given the software development practices in Python and especially in the AI space, I'm very pessimistic about this feature.

While I'm happy to see optional GIL approved and happening,

I also suspect that the GIL has saved us from debugging reentrant and/or dangerously concurrent code for years, and I salute the GIL for forcing us to build Arrow for IPC in Python, in particular.

Someday, URI attributes in CPython docstrings might specify which functions are constant time, non re-entrant, functions.

Reentrancy (computing): https://en.wikipedia.org/wiki/Reentrancy_(computing)

Global Interpreter Lock: https://en.wikipedia.org/wiki/Global_interpreter_lock

What is Vax specific stack behaviour?

I wonder why so many library developers even chose to build native libraries on the shaky and poorly-architected foundation that Python is.

Even writing a JVM native JNI library would have allowed to avoid a lot of that pain (and the library would have been useable from Clojure, Kotlin , Scala, JRuby[1], Jython[2], Java, etc) without any painful threading issues.

[1] which I’m aware of having been used in production by companies in the past

[2] which I’m aware has been quite a bit under maintained for the last several years

Because with the GIL it was dead simple to glue a C library into Python, and also was the canonical way to address hot inner loops in Python: rewrite into C. Nothing fancy but a little trial and error with module loading and you get 30% speed ups without being a great C programmer.

I don’t think it’s false to say that the ease of moving hot spots into C is part of the reason Python has been so successful for thirty years.

I hope this works, but I am very sceptical about being able to port code that worked with a locking solution provided for the enthusiast trying out C working without running into concurrency bugs.

My understanding is the thing about the binding system that drove adoption more than anything was due to how easy it was to generate bindings for an existing C library. This drove stdlib expansion and allowed rapid repurpose of huge amounts of long-standing and popular C libraries, and it also added instant credibility for those that already trusted those libraries. This helped avoid the chicken and egg problem of not enough devs for a serious stdlib, but not serious enough stdlib to draw dev (which is where most languages, even good ones, die).

I distinctly remember that during the time period where Python grew from “minor” to “dominate” (roughly 1995-2005), doing Python dev was often a process of answering “are there bindings for that?” And usually _there were_, because of that tooling.

btw, many C extensions release GIL already e.g., one Python thread can do regex work, another some number crunching, yet another waiting IO--all in parallel.

C extensions are a different use case than accessing a C library using `ctypes`. The former allows intimate interactions with Python objects and therefore requires the GIL. The latter should only cause trouble if the C library executes callbacks on another thread. In that case, a Python thread is created for every invocation, which could cause race conditions with Python code. However, this problem also exists in GIL mode. In most cases, foreign libraries usually have Pythonic wrappers that should prevent some of these issues.

I think there are several reasons:

- The history is backwards: it isn’t that devs wanted to make a native library and then chose Python, it’s that they chose Python and then they needed a native library.

- Python works very well for scripts and small programs, and decently well for medium-size programs. This makes libraries with concrete purposes very useful and productive. If your library, say, helps devs do some basic calculation with time series, the ability to be used in quick scripts is a big plus.

- The C API is fairly good, and libraries such as pybind11 make it even better. You don’t need a lot of code or boilerplate for an extension.

Actually, Java virtual threads have a similar problem with JNI. Your virtual thread gets pinned to a core if you call native code. This isn't as bad as the python GIL but it still limits the usefulness of virtual threads if they can't migrate to other cores.

Reply on news.ycombinator.com