As someone who has read the entirety of those thread and is not a core-dev but having some experience with breaking and non-breaking changes at scale, from my perspective:

1. This is a common syntax for an existing idea that is intuitive given other existing syntax (comprehensions)
2. This would introduce a change that usage breaks backwards compatibility with older interpreters, which means if a core open source project uses it, their consumers will either need to update their interpreter to keep up to date or risk a fork in one of their code bases to stay long-term maintained

I agree that point 2 should never be taken lightly, so realistically it may need a PEP to justify its appearance, but I’ve also never seen a syntactical addition to Python quite as idiom-shifting as pattern-matching in 3.10, so it’s not like it’s never been done.

From my viewpoint, the discussion did have a lot of adversarial tone which I understood not as bike-shedding (contributing only to easily-understood problems/suggestions), but similarly to the “symbols versus words” balance in that shorter syntax isn’t necessarily more readable or easier to read about and trying to keep the tenet that there should be preferably only one way to express the concept (or at least preferentially fewer).  Also, I’m sure that there is a lot of bike-shedding that can happen in such an open forum (I mean, I’m doing it right now in a way) and that it can cause reviewers to build callouses and may cause some good ideas to get overlooked in favor of stability of interfaces.

However, I think the myriad of existing expression possibilities that were suggested for this situation actually is an argument that if there is a clearly more expressive and readable way of representing it, then it could actually be an improvement that could help reduce unnecessary plurality.  Given it doesn’t diverge from extant pythonic patterns (e.g. comprehensions), is intuitive to use and read (IMHO, given any code can be made unintelligible) and that there are multiple instances in my own code where it would have been the most readable way to express this idea, I’d be for it, especially if it were simply being rolled into a minor version already containing a syntactic addition.


On Wed, Mar 9, 2022 at 3:11 PM Greg Ewing <> wrote:
On 8/03/22 12:32 pm, Chris Angelico wrote:
> All I can see is that
> changes get proposed on typing-sig and actually make it into the
> language, but changes that get proposed on python-ideas are invariably
> shot down in flames,

Typing is an area of Python that is under active development, so
it is somewhat malleable, and there are still real problems that
actually need to be solved.

On the other hand, the core syntax of Python has been well
established for a long time. Most of the proposals for adding
to it nowadays tend to be of the "wouldn't it nice if..."
variety that are not addressing anything that's widely seen
as a problem. It's not surprising that such suggestions
rarely succeed.

> no matter how good or bad.

If an idea can be shot down in flames that easily, it wasn't
really such a good idea when seen in the wider context.

It's not just the merits of the idea itself that need to be
considered, but whether it brings enough benefit to be worth
the disruption of introducing it. As Python matures and
solidifies, that bar becomes harder and harder to clear.

Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct: