https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-...
I'm astounded that a change which will release untold heisenbugs into the wild is being considered. It changes my view of Python. In terms of inducing subtle, silent breakage in existing code, it reminds me of this horrifying change from PHP 8:
https://www.php.net/manual/en/migration80.incompatible.php#m...
The only thing horrifying to me is that that behaviour was there in the first place!
I would be 100% behind those fixes, I assume from your response that you would not do them in the sake of backwards compatibility.
What would be your solution? To always have these idiosyncrasies in the language, or did you have a problem with how the fixes were implemented or rolled out?
Sounds like they’re going to make it opt-in (or opt-outable) if they do merge it.
Not sure I understand that. The proposal is not to simply get rid of the GIL, but to have a two-tier mechanism that ensures correctness with all the C source that uses the macros it should use and doesn’t mess with refcounts behind Python’s back (doing sketchy stuff usually ends up in pain)