I don't like `except group` or any variant with soft keywords.
As Brandt just commented, this proposal is a no go due to confusion with function calls. I'll respond below anyway because looking through it was an interesting experience
I'll list a few reasons here:
1. `try: .. except group:` is a valid syntax today. And it will continue to be valid syntax. Having both `try: .. except group:` (catch exception `group`) and `try: .. except group E:` (catch exceptions of E into a group) in the same grammar worries me.
1a. It can be especially confusing if someone has a local/global variable called `group`.
This is a valid point, also raised by Pablo over WhatsApp (which happens to work today!). The particular hairy example has to do with your next point so let's go there first...
1b. Or, for example, if a user forgets to type `E` and leaves just `except group` it would fallback to the regular try..except behavior. And it would be a runtime error ("group" is undefined).
Right. Worse yet, this wouldn't be a runtime error UNLESS user code raises an exception within that try: block. Otherwise Python would happily take the unbound name and run with it:
>>> try:
... ...
... except group:
... ...
...
Ellipsis
When you raise:
>>> try:
... 1/0
... except group:
... ...
...
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
ZeroDivisionError: division by zero
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<stdin>", line 3, in <module>
NameError: name 'group' is not defined
This is pretty confusing and in my eyes disqualifies the "except group" proposal. Pablo also claims it would be very hard to generate good error messages due to this and I can see why. My initial idea here was to modify this received `NameError` just like we do in other cases with the new "Did you mean" helper:
>>> arg = 1
>>> ar
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'ar' is not defined. Did you mean: 'arg'?
>>> def f():
... ar
...
>>> f()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 2, in f
NameError: name 'ar' is not defined. Did you mean: 'arg'?
We could potentially do something similar to generate better error messages for "except group" confusion, right? Only we can't if `group` happens to be bound as a name in a reachable scope which Larry points out is a popular name. In this scenario any syntax errors would end up with terribly confusing TypeErrors or AttributeErrors and so on. This is unacceptable.
1c. This will be all even more complicated because syntax highlighters in IDEs and on sites like GitHub will likely just always highlight `except group` as a pair of keywords (even in `except group:` variant).
This would a minor annoyance but definitely true.
2. I'm not sure I like the "sound" of it. IMO it would make more sense to write `except all E`, but `all()` is a built-in and so this would be at odds with (1).
That I disagree with. "except KeyError" reads like "except if there's a KeyError". "except group KeyError" reads like "except if there's a group of KeyErrors". And if you said, "except group KeyError as eg", an ExceptionGroup with KeyErrors would be exactly what you're getting under `eg`.
3. This is a niche feature. People who use async/await will get used to `except*` in no time. `except*` is also about unpacking in some metaphysical sense (looks similar enough to `*args` in function signatures to me) so I think it reads just fine.
Agreed. Except-star will be fine, too.
So I'm -1 on `except group` or any variant that uses soft keywords. If the SC considers making `group` a proper keyword I can possibly change my mind on this.
Making `group` a proper keyword is a no go. With Brandt's arguments, the entire idea is a no go. It's a bummer but I have to agree with the concerns raised.
- Ł