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...
+1 On Sun, 2021-05-09 at 16:45 +0000, Thomas Grainger wrote:
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... _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WQOMBT... Code of Conduct: http://python.org/psf/codeofconduct/
On Sun, May 9, 2021 at 9:48 AM Thomas Grainger <tagrain@gmail.com> wrote:
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: ... ```
-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:
On Sun, May 9, 2021 at 9:48 AM Thomas Grainger <tagrain@gmail.com <mailto:tagrain@gmail.com>> wrote:
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 <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: ... ```
-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.
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:
now that python2.7 is EOL, it might be worth resurrecting this syntax [...] except E1, E2, E3 as e:
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:
On Sun, May 09, 2021 at 04:45:55PM -0000, Thomas Grainger wrote:
now that python2.7 is EOL, it might be worth resurrecting this syntax [...] except E1, E2, E3 as e:
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?
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:
On Mon, May 10, 2021 at 9:57 AM Steven D'Aprano <steve@pearwood.info> wrote:
On Sun, May 09, 2021 at 04:45:55PM -0000, Thomas Grainger wrote:
now that python2.7 is EOL, it might be worth resurrecting this syntax [...] except E1, E2, E3 as e:
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?
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.
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?
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):
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-change-the-world/>
On Mon, May 10, 2021 at 12:49 PM Guido van Rossum <guido@python.org> wrote:
On Sun, May 9, 2021 at 5:08 PM Chris Angelico <rosuav@gmail.com> wrote:
On Mon, May 10, 2021 at 9:57 AM Steven D'Aprano <steve@pearwood.info> wrote:
On Sun, May 09, 2021 at 04:45:55PM -0000, Thomas Grainger wrote:
now that python2.7 is EOL, it might be worth resurrecting this syntax [...] except E1, E2, E3 as e:
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?
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.
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?
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.
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:
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.
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?
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,
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?
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.
"My editor doesn't recognise this error" is not a strong argument in favour of a change that otherwise adds no new functionality.
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):
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:
a := len('abc') File "<stdin>", line 1 a := len('abc') ^ SyntaxError: invalid syntax (a := len('abc')) 3
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:
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?
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,
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?
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.
"My editor doesn't recognise this error" is not a strong argument in favour of a change that otherwise adds no new functionality.
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):
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:
a := len('abc') File "<stdin>", line 1 a := len('abc') ^ SyntaxError: invalid syntax (a := len('abc')) 3
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.
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
On 10/05/2021 12:43, Chris Angelico wrote:
On Mon, May 10, 2021 at 9:36 PM Steven D'Aprano <steve@pearwood.info> wrote:
On Mon, May 10, 2021 at 10:04:58AM +1000, Chris Angelico wrote:
Is there an aim beyond saving two characters? It would remove a level of frustration. I've watched a lot of novice
On Mon, May 10, 2021 at 9:57 AM Steven D'Aprano <steve@pearwood.info> wrote: [...] 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, 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?
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. "My editor doesn't recognise this error" is not a strong argument in favour of a change that otherwise adds no new functionality.
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): 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:
a := len('abc') File "<stdin>", line 1 a := len('abc') ^ SyntaxError: invalid syntax (a := len('abc')) 3
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.
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.
+0.9. A practical solution, although it makes the language definition more complicated. Practicality beating purity. Rob Cliffe
Static analysis and factorisation, I sub ! :D Le mar. 11 mai 2021 à 01:47, Rob Cliffe via Python-ideas < python-ideas@python.org> a écrit :
On 10/05/2021 12:43, Chris Angelico wrote:
On Mon, May 10, 2021 at 9:36 PM Steven D'Aprano <steve@pearwood.info> wrote:
On Mon, May 10, 2021 at 10:04:58AM +1000, Chris Angelico wrote:
Is there an aim beyond saving two characters? It would remove a level of frustration. I've watched a lot of novice
On Mon, May 10, 2021 at 9:57 AM Steven D'Aprano <steve@pearwood.info> wrote: [...] 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, 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?
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. "My editor doesn't recognise this error" is not a strong argument in favour of a change that otherwise adds no new functionality.
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): 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:
a := len('abc') File "<stdin>", line 1 a := len('abc') ^ SyntaxError: invalid syntax (a := len('abc')) 3
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.
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.
+0.9. A practical solution, although it makes the language definition more complicated. Practicality beating purity. Rob Cliffe _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7PRV7O... Code of Conduct: http://python.org/psf/codeofconduct/
+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