I think that's a bit different. 32 to 64 - you could test whether it works. Same for arm. Same for y2k. Sure, maybe the testing wouldn't cover the failing case, but the testing you did would be deterministic. But here? Test all you want and the answer is: it's either correct or you haven't triggered the right race yet.
Yes, it is different because nobody would be forced to run the interpreter without the GIL. Applications where race conditions are unacceptable can keep using the GIL build. Even the `--disable-gil` build can be forced to keep using the GIL.
I mean going from text to unicode did pose a huge problem for python specifically.
I have PTSD from that transition.
Re:No-GIL mode coming for Python
by umanwizard on Saturday July 29, 2023 @08:20AM
(#36919555)
I’m not worried about the difficulty of migration; I’m worried that the end state might actually be worse than what we have now.
No-GIL is a much smaller shift. It can follow the same transition path without radically breaking things. And if some things do break, there would be a well-defined way to handle those cases.
We all somehow survived those. Glad to see forward motion on this. It will open up a lot more terrain that has been marked off as untenable.
One of the things about early Swift that they got right was building breaking changes into the promise. Everyone knew where they stood and adjusted just fine. Sometimes I wish Python would take the same path.