Very exciting. Sam Gross took a very bold move with his "I don't need a yes/no right now, but I do need to know what acceptance looks like, and this issue has b

Very exciting. Sam Gross took a very bold move with his "I don't need a yes/no right now, but I do need to know what acceptance looks like, and this issue has been languishing." [0] That interaction could have gone a lot of different ways (especially as a neurospicy engineer myself and knowing the overall spice level in the computer world) but it sounds like that was the exact kick the council needed. It is still a long and winding path (double-digit engineer-years) to get a no-gil python, but at least there exists a proper path from the looks of it. The hardest part by far will be ensuring the correctness of all existing codebases. It's one thing to say you don't want a 2->3 repeat. It's another altogether if you were to claim no breaking changes, but fear of bugs resulted in folks avoiding the upgrade in practice. Making gil/no-gil even a compile-time switch will absolutely increase the maintenance cost. But I think in the long run, all this effort will be worth it, as I would claim the GIL is a lightning rod for python criticism. Just peruse any HN thread about python and parallelism to see what I mean. Maybe it's because it's the one thing folks can point directly to and say "this is why python isn't as fast as it could be" without understanding the decades of context. It's kind of the Final Boss of Chesterton's Fences in that regard. [0] https://github.com/python/steering-council/issues/188#issuecomment-1581534250 https://github.com/python/steering-council/issues/188#issuec...