A better question is: do we guarantee that it will always stop the world?

We stop the world, temporarily enable the GIL, then resume (but with only one thread now holding the GIL), and the run the C extension initialization code.

I think you might still need the locks in this example because of isolated sub interpreters each with their own GIL.

We haven't explicitly guaranteed the stop the world behavior, but it'll probably be difficult to change in the future.

I think you might still need the locks in this example because of isolated sub interpreters each with their own GIL.

Subinterpreters switch to the main interpreter to import an extension, so the GIL synchronizes it.

Subinterpreters switch to the main interpreter to import an extension, so the GIL synchronizes it.

Well, that's something I'd like to change for 3.15 :)

Let's play it safe and keep our options open?
If you know the current implementation details, it's easy to leave this out.

I'll yield, but I'm worried that it would break too much code to be feasible (or worth doing). I think all third-party extensions currently assume no other threads, right? Maybe we could make this opt-in.