Right, I should have phrased it better - did not intend to make it sound like criticism of your reply. Was just aiming at the tendency to dismiss valid concerns with "it's actually a good thing we don't have it" or "it can't be done well".
Of course changing the concurrency guarantees the code relies on and makes assumptions about is one of the most breaking changes that can be made to a language, with very unpleasant failure modes.
Understood. There has been some amount of that in the past. And probably this kind of pushback will rise up again as the work starts to materialize. I think some are a bit fearful of the potential bad consequences - and it remains unclear which will materialize and which will be non-issues.
And of course some have other things they wish to see improved instead, cause they are satisfied with current state. Actually many will be quite happy with (or at least have accepted) the current state - cause those that were/are not probably do not use Python much!
What I see from the development team and close community so far has been quite trust building for me. Slow and steady, gradual integration and testing with feature flags, improving related areas in preparation (like better/simplified C APIs), etc.
Of course changing the concurrency guarantees the code relies on and makes assumptions about is one of the most breaking changes that can be made to a language, with very unpleasant failure modes.