> On 6 Oct 2021, at 18:05, Yury Selivanov <yselivanov...@gmail.com> wrote: > > 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.
- Ł
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HKY6KZO3267MUYWNJ7664QZIOLCTPZWM/ Code of Conduct: http://python.org/psf/codeofconduct/
