Controversial is correct. A poll showed a majority (65%) of core developers opposed to this particular proposal, and a plurality (44%) opposed to pattern matching altogether.
https://discuss.python.org/t/gauging-sentiment-on-pattern-ma...
* A majority (56%) of responders want some form of pattern matching.
* Exactly half of all responders, forming nearly 90% of the above majority, are fine with that form being PEP 634.
* There are differing opinions about supporting PEPs, but a supermajority (70%) of those who agree with PEP 634 are fine with it alone.
The fact that it was possible to express more nuance when agreeing with PEP 634 shouldn't diminish their voice against those who reject the idea altogether.
That half includes those who voted for "accept 634 + 640" or "accept 634 + 642", whom I doubt are entirely happy with the decision to accept PEP 634 and reject 640 & 642.
That said, I interpret this part:
> PEP 642’s proposed syntax does not seem like the right way to solve the jagged edges in PEP 634’s syntax
to mean that this is merely an initial spec. Those unhappy with the syntax can avoid using it for now, there are no breaking changes. It took a couple iterations to refine the async syntax too, remember, and (IMHO) we arrived at a clean-enough version of it. I have hope!
If you decide to act on this 34% anyway, you are only just telling your community that their opinion doesn't really matter. Which might explain why 60% of the eligible voters did not bother.
agreed. I'm being pedantic on more specific conclusions, but it wasn't the best move. Even if I'm somewhere between "fine" and "happy" about this, personally.
An explicit "do not care" or "none of the above" option in that poll would have shed more light into this.