Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`
now that python2.7 is EOL, it might be worth resurrecting this syntax as discussed in https://www.python.org/dev/peps/pep-3100/#id13 eg, python 3.11 could support ``` try: ... except (E1, E2, E3) as e: ... ``` as equivalent to ``` try: ... except E1, E2, E3 as e: ... ``` see also https://mail.python.org/archives/list/python-dev@python.org/thread/HSN6ESRB4...
On Sun, May 9, 2021 at 9:48 AM Thomas Grainger <tagrain@gmail.com> wrote:
-1 I think you really mean you want Python to accept the form without the parenthesis. I don't like it because it's easy to read that as except E1, E2, (E3 as e): and I don't think saving two characters is worth the disruption caused by people being able to write Python 3.11 code that won't work in Python 3.10. Many people would not adopt the new syntax for that reason. --- Bruce
On 2021-05-09 21:11, Bruce Leban wrote:
I'm not keen on it either. On the other hand, binding to e for E3 but not for E1 or E2 would be kind of weird, and "e = E1, E2, E3" is valid. On the third hand(!), 'as' is used in the 'import' and 'with' statements, where it binds to only one preceding item.
On Sun, May 9, 2021 at 1:22 PM MRAB <python@mrabarnett.plus.com> wrote:
On the third hand(!), 'as' is used in the 'import' and 'with' statements, where it binds to only one preceding item.
Thanks. Yes, that was what I was thinking that it's weird for "as" to have different precedence in different statements, and I should have said that explicitly. EIBTI of course. --- Bruce
On Sun, May 09, 2021 at 04:45:55PM -0000, Thomas Grainger wrote:
What advantages will this new syntax bring us? Will it allow us to do things that we can't currently do? When would you use it in preference to the existing syntax? By this I mean both under what circumstances, and at what time (tomorrow? in a year? in ten years?). Is there an aim beyond saving two characters? -- Steve
On Mon, May 10, 2021 at 9:57 AM Steven D'Aprano <steve@pearwood.info> wrote:
It would remove a level of frustration. I've watched a lot of novice programmers, and some intermediate programmers, run into a source of (now completely unnecessary) pain that changing this: except ValueError: into this: except ValueError, TypeError: doesn't work. Yes, it's a quick SyntaxError, but the editor won't show it up (since most editors are Python 2 compatible, and wouldn't be checking this level of syntax anyway), so there's X amount of time spent coding, then go to run the thing, and it won't work the way they expect it to. If it weren't for the Python 2 issues, would there be any good reason for demanding parentheses? We don't need them in a for loop: for i, thing in enumerate(stuff): It's true that adding "as e" makes it read oddly, but that's the only real point against it - other than a question of "when". ChrisA
On Sun, May 9, 2021 at 5:08 PM Chris Angelico <rosuav@gmail.com> wrote:
We've had arguments like this before, and we've usually taken the position that we shouldn't compromise the language to cater to imperfect tools. Editors that are Python-aware should just catch up with Python 3 syntax. Editors that don't check this level of syntax definitely shouldn't be used as motivation at all. (I just tried this in the latest VS Code Insiders edition, and the Python support does catch this.) Also, I wonder what made those users think to try that? Maybe they read a tutorial or StackOverflow issue suggesting the Python 2 syntax?
Someone else (Steven?) already pointed out in this thread that there are other places where 'as <target>' or 'as <identifier>' as used, the relative precedence of commas and 'as' is different than the proposal here: import foo.bar as foobar, bar.foo as barfoo is parsed as import (foo.bar as foobar), (bar.foo as barfoo) Similarly, with something as foo, something_else as bar: ... is parsed as with (something as foo), (something_else as bar): ... And similar in pattern matching. It's true that adding "as e" makes it read oddly, but that's the only
real point against it - other than a question of "when".
I think never is a perfectly fine answer. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
On Mon, May 10, 2021 at 12:49 PM Guido van Rossum <guido@python.org> wrote:
It's the obvious way to extend from a single exception name to two. Think of it *without* the "as" clause and it becomes less clear that the parentheses are necessary.
I think "because of the possibility of the as clause, it's not worth doing this" is a perfectly fine answer too. It would be nice if "except TypeError, ValueError:" could be made valid, but that may not be worth the hassle. ChrisA
On Mon, May 10, 2021 at 10:04:58AM +1000, Chris Angelico wrote:
On Mon, May 10, 2021 at 9:57 AM Steven D'Aprano <steve@pearwood.info> wrote:
[...]
Is there an aim beyond saving two characters?
You say it is completely unnecessary, but is it? The way `as` currently works and the way this proposal will have it work are just different enough to make me fret. import spam, eggs, cheese, aardvark as hovercraft with spam, eggs as f except ValueError, KeyError, TypeError as err How long will it be before people, fooled by the similarity to other uses of `as`, try writing this: except ValueError as verr, KeyError as kerr, TypeError as terr and how soon after that before people propose it as an actual feature?
"My editor doesn't recognise this error" is not a strong argument in favour of a change that otherwise adds no new functionality.
True, but we do need them here: [1,x for x in range(3)] even though there is only one possible interpretation of the code. It can't be `[1, generator]` because the hypothetical generator expression isn't parenthesized. Sometimes we require parens as a "belts and braces" sort of thing. There's no *actual* syntactic ambiguity, but we require the parens just to be sure:
I feel the same about this proposal. Without the brackets grouping the exceptions, it feels too close to binding only the last one in the group rather than the entire tuple of exceptions. -- Steve
On Mon, May 10, 2021 at 9:36 PM Steven D'Aprano <steve@pearwood.info> wrote:
What if the parens could be omitted only if there's no 'as' clause? That eliminates the ambiguity. Is it really necessary to clarify what "except TypeError, ValueError:" means, either to the interpreter or to another programmer? Every objection has been based on the confusion of "except TypeError, ValueError as e:", and I agree with that. ChrisA
+1 and -1 at the same time. I feel like :- "This makes sense", try: # something except E1, E2, E3: # something "This doesn't make sense", try: # something except E1, E2, E3 as e: # something The second one according to this idea would be parsed as, try: # something except (E1, E2, E3) as e: # something Though it would seem this way to people, try: # something except E1, E2, (E3 as e): # something The first example I gave is much more logical. Because (E1, E2, E3) and E1, E2, E3 are the same thing logically.
how about: ``` try: ... except E1 | E2 | E3 as e: ... ``` it's syntactically valid but is this again: https://bugs.python.org/issue12029
On Sun, May 9, 2021 at 9:48 AM Thomas Grainger <tagrain@gmail.com> wrote:
-1 I think you really mean you want Python to accept the form without the parenthesis. I don't like it because it's easy to read that as except E1, E2, (E3 as e): and I don't think saving two characters is worth the disruption caused by people being able to write Python 3.11 code that won't work in Python 3.10. Many people would not adopt the new syntax for that reason. --- Bruce
On 2021-05-09 21:11, Bruce Leban wrote:
I'm not keen on it either. On the other hand, binding to e for E3 but not for E1 or E2 would be kind of weird, and "e = E1, E2, E3" is valid. On the third hand(!), 'as' is used in the 'import' and 'with' statements, where it binds to only one preceding item.
On Sun, May 9, 2021 at 1:22 PM MRAB <python@mrabarnett.plus.com> wrote:
On the third hand(!), 'as' is used in the 'import' and 'with' statements, where it binds to only one preceding item.
Thanks. Yes, that was what I was thinking that it's weird for "as" to have different precedence in different statements, and I should have said that explicitly. EIBTI of course. --- Bruce
On Sun, May 09, 2021 at 04:45:55PM -0000, Thomas Grainger wrote:
What advantages will this new syntax bring us? Will it allow us to do things that we can't currently do? When would you use it in preference to the existing syntax? By this I mean both under what circumstances, and at what time (tomorrow? in a year? in ten years?). Is there an aim beyond saving two characters? -- Steve
On Mon, May 10, 2021 at 9:57 AM Steven D'Aprano <steve@pearwood.info> wrote:
It would remove a level of frustration. I've watched a lot of novice programmers, and some intermediate programmers, run into a source of (now completely unnecessary) pain that changing this: except ValueError: into this: except ValueError, TypeError: doesn't work. Yes, it's a quick SyntaxError, but the editor won't show it up (since most editors are Python 2 compatible, and wouldn't be checking this level of syntax anyway), so there's X amount of time spent coding, then go to run the thing, and it won't work the way they expect it to. If it weren't for the Python 2 issues, would there be any good reason for demanding parentheses? We don't need them in a for loop: for i, thing in enumerate(stuff): It's true that adding "as e" makes it read oddly, but that's the only real point against it - other than a question of "when". ChrisA
On Sun, May 9, 2021 at 5:08 PM Chris Angelico <rosuav@gmail.com> wrote:
We've had arguments like this before, and we've usually taken the position that we shouldn't compromise the language to cater to imperfect tools. Editors that are Python-aware should just catch up with Python 3 syntax. Editors that don't check this level of syntax definitely shouldn't be used as motivation at all. (I just tried this in the latest VS Code Insiders edition, and the Python support does catch this.) Also, I wonder what made those users think to try that? Maybe they read a tutorial or StackOverflow issue suggesting the Python 2 syntax?
Someone else (Steven?) already pointed out in this thread that there are other places where 'as <target>' or 'as <identifier>' as used, the relative precedence of commas and 'as' is different than the proposal here: import foo.bar as foobar, bar.foo as barfoo is parsed as import (foo.bar as foobar), (bar.foo as barfoo) Similarly, with something as foo, something_else as bar: ... is parsed as with (something as foo), (something_else as bar): ... And similar in pattern matching. It's true that adding "as e" makes it read oddly, but that's the only
real point against it - other than a question of "when".
I think never is a perfectly fine answer. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
On Mon, May 10, 2021 at 12:49 PM Guido van Rossum <guido@python.org> wrote:
It's the obvious way to extend from a single exception name to two. Think of it *without* the "as" clause and it becomes less clear that the parentheses are necessary.
I think "because of the possibility of the as clause, it's not worth doing this" is a perfectly fine answer too. It would be nice if "except TypeError, ValueError:" could be made valid, but that may not be worth the hassle. ChrisA
On Mon, May 10, 2021 at 10:04:58AM +1000, Chris Angelico wrote:
On Mon, May 10, 2021 at 9:57 AM Steven D'Aprano <steve@pearwood.info> wrote:
[...]
Is there an aim beyond saving two characters?
You say it is completely unnecessary, but is it? The way `as` currently works and the way this proposal will have it work are just different enough to make me fret. import spam, eggs, cheese, aardvark as hovercraft with spam, eggs as f except ValueError, KeyError, TypeError as err How long will it be before people, fooled by the similarity to other uses of `as`, try writing this: except ValueError as verr, KeyError as kerr, TypeError as terr and how soon after that before people propose it as an actual feature?
"My editor doesn't recognise this error" is not a strong argument in favour of a change that otherwise adds no new functionality.
True, but we do need them here: [1,x for x in range(3)] even though there is only one possible interpretation of the code. It can't be `[1, generator]` because the hypothetical generator expression isn't parenthesized. Sometimes we require parens as a "belts and braces" sort of thing. There's no *actual* syntactic ambiguity, but we require the parens just to be sure:
I feel the same about this proposal. Without the brackets grouping the exceptions, it feels too close to binding only the last one in the group rather than the entire tuple of exceptions. -- Steve
On Mon, May 10, 2021 at 9:36 PM Steven D'Aprano <steve@pearwood.info> wrote:
What if the parens could be omitted only if there's no 'as' clause? That eliminates the ambiguity. Is it really necessary to clarify what "except TypeError, ValueError:" means, either to the interpreter or to another programmer? Every objection has been based on the confusion of "except TypeError, ValueError as e:", and I agree with that. ChrisA
+1 and -1 at the same time. I feel like :- "This makes sense", try: # something except E1, E2, E3: # something "This doesn't make sense", try: # something except E1, E2, E3 as e: # something The second one according to this idea would be parsed as, try: # something except (E1, E2, E3) as e: # something Though it would seem this way to people, try: # something except E1, E2, (E3 as e): # something The first example I gave is much more logical. Because (E1, E2, E3) and E1, E2, E3 are the same thing logically.
how about: ``` try: ... except E1 | E2 | E3 as e: ... ``` it's syntactically valid but is this again: https://bugs.python.org/issue12029
participants (10)
-
Bruce Leban -
Chris Angelico -
Guido van Rossum -
Ir. Robert Vanden Eynde -
MRAB -
Paul Bryan -
Rob Cliffe -
Shreyan Avigyan -
Steven D'Aprano -
Thomas Grainger