+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 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 Sun, May 9, 2021 at 1:22 PM MRAB 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 Mon, May 10, 2021 at 9:57 AM Steven D'Aprano 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 Mon, May 10, 2021 at 12:49 PM Guido van Rossum wrote:

On Sun, May 9, 2021 at 5:08 PM Chris Angelico wrote:

...

On Mon, May 10, 2021 at 9:57 AM Steven D'Aprano 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 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

how about: ``` try: ... except E1 | E2 | E3 as e: ... ``` it's syntactically valid but is this again: https://bugs.python.org/issue12029

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 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 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/