On 10/6/21 2:34 PM, Łukasz Langa wrote:
On 6 Oct 2021, at 12:06, Larry Hastings <email@example.com mailto:firstname.lastname@example.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.