[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`

[Ir. Robert Vanden Eynde]

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:
> >>> 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 "", 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-le...@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/7PRV7OMPN52GOFF6HLNPCCD7FBE3MQ2J/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/L7ERN3BHWC652L622ONIRARNWACUJRJT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`

[Rob Cliffe via Python-ideas]

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:

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 "", 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-le...@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/7PRV7OMPN52GOFF6HLNPCCD7FBE3MQ2J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`

[Thomas Grainger]

how about:

```
try:
...
except E1 | E2 | E3 as e:
...
```

it's syntactically valid but is this again: https://bugs.python.org/issue12029
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/MKUMC6CCGLRY6IJJF2WD6CSMQUZN5Z2Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`

[Chris Angelico]

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:
> > 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 "", 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
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/Z43NB4QKWPP5X7HTSE4VG3YJ5XQENVY2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`

[Steven D'Aprano]

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 "", 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
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/PDSS7VQ26UTOLXBJDJDS5UKAYBZWGHFY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`

[Shreyan Avigyan]

+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.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/J7FUCBFV2TPA7SY3DYNPEBGZ354CYNFR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`

[Chris Angelico]

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 -, 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 ' or 'as ' 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
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/MGWLAJKBL5EC73L3TV4VQUHI3NADNDR3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`

[Guido van Rossum]

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 -, 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 ' or 'as ' 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?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/7XREC6PDF2YG55WVDXHJHWZQJNYJIC7X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`

[Chris Angelico]

On Mon, May 10, 2021 at 9:57 AM Steven D'Aprano  wrote:
>
> On Sun, May 09, 2021 at 04:45:55PM -, 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
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/6I7XQYSNUSF76CZQBSYDYVVOXYHDOBER/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`

[Steven D'Aprano]

On Sun, May 09, 2021 at 04:45:55PM -, 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
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/KWAXL3VTUNWSDTRMQ32POXDMEPQZV42B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`

[Bruce Leban]

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
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/PNYBK5SEGYQEAL2WS62MGWW475QBD6MZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`

[MRAB]

On 2021-05-09 21:11, Bruce Leban wrote:



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.



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.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/WW7SPE25HSXTRSMM7QMXZAX4ZIXLPOTP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`

[Bruce Leban]

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
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/7NSJP4CYS37DLKT7GZTZRO6B4CMILRJJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`

[Shreyan Avigyan]

+1
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/OEU3NVLZVFIEUIRSYONB5AQZRVMRJWF3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`

[Paul Bryan]

+1

On Sun, 2021-05-09 at 16:45 +, 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-...@python.org/thread/HSN6ESRB4BD6IUIPKLMNP4TPBQPWHBFK/
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@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/WQOMBT4Z22EIFB53WN54E52AYS3QBKAV/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/GERIYIVX6XGH6JILDWSF4ISKC5IWQ3MN/
Code of Conduct: http://python.org/psf/codeofconduct/