On 6 Oct 2021, at 12:06, Larry Hastings <larry@hastings.org> wrote:

It seems like, for this to work, "group" would have to become a keyword.

No, just like `match` and `case` didn't have to.

This would play havoc with a lot of existing code.

Extraordinary claims require extraordinary evidence, Larry. I maintain this will be entirely backwards compatible.

My claim is that making "group" a hard-coded keyword, visible at all times, and thus no longer permitting use of "group" as an identifier, would play havoc with a lot of existing code.  I don't think it's an extraordinary claim to say that "group" is a reasonably popular identifier.  For example, I offer the 1,117 uses of the word "group" in the Python 3.10.0 Lib/ directory tree.  (I admit I didn't review them all to see which ones were actual identifiers, and which ones were in strings or documentation.)

If the proposal is to add it as some "it's only a keyword in this context" magic thing, a la how "async"/"await" were "soft keywords" in 3.5, and if we otherwise would permit the word "group" to be used as an identifier in perpetuity--okay, it won't cause this problem.

We can even make its error message smarter than the default NameError, since -- as I claim -- it's terribly unlikely somebody would mean to name their dynamic exception collection "group".

I concede I don't completely understand PEP 654 yet, much less the counter-proposals flying around right now.  But it does seem like "except group" has the potential to be ambiguous, given that "group" is a reasonably popular identifier.

/arry