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