> Let the people with the nameless closed-source stuff stick with that.
Let's hope it becomes a teachable moment.
Let's hope it becomes a teachable moment.
Also it's important to remember that a lot of of material contributions to the community (either to the foundation, via jobs, or even open-sourcing part of their internal stack) might be coming from closed source in some way. It's not wise to ignore that & I think the core team is rightfully cognizant of needing to balance that (balance - not tip to one extreme or the other).
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...
Sounds like they’re going to make it opt-in (or opt-outable) if they do merge it.
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?
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)