[Python-Dev] PEP 463: Exception-catching expressions

[Rob Cliffe]

My 2 cents worth:


On 21/02/2014 12:42, Chris Angelico wrote:
> On Fri, Feb 21, 2014 at 10:35 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Great work on this Chris - this is one of the best researched and
>> justified Python syntax proposals I've seen :)
Hear, hear!  ("Praise from the praiseworthy is praise indeed" - Tolkien.)

Small point: in one of your examples you give a plug for the PEP "note 
the DRY improvement".
I would suggest that similarly
     perhaps in your Lib/tarfile.py:2198 example you point out the 
increase in readability due to the 2 lines lining up
     in your Lib/ipaddress.py:343 example you point out that the new 
form is probably an improvement (i.e. probably closer to the author's 
intention) as it will NOT catch an AttributeError evaluating 
"ips.append" (this would matter e.g. if "append" were mis-spelt).  YOU 
are clearly aware of this but it would often escape the casual reader.
>>> Retrieving a message from either a cache or the internet, with auth
>>> check::
>>>
>>>      logging.info("Message shown to user: %s",((cache[k]
>>>          except LookupError:
>>>              (backend.read(k) except OSError: 'Resource not available')
>>>          )
>>>          if check_permission(k) else 'Access denied'
>>>      ) except BaseException: "This is like a bare except clause")
>> I don't think taking it all the way to one expression shows the new
>> construct in the best light. Keeping this as multiple statements
>> assigning to a temporary variable improves the readability quite a
>> bit:
I agree, it looks scary (too many branches in one statement).  The 
shorter the example, the more convincing.
> Yeah, good point. I tried to strike a balance between simple and
> complex examples, but it's hard to judge.
>
>
>>> Capturing the exception object
>>> ------------------------------
>>>
>>> An examination of the Python standard library shows that, while the use
>>> of 'as' is fairly common (occurring in roughly one except clause in five),
>>> it is extremely *uncommon* in the cases which could logically be converted
>>> into the expression form.  Its few uses can simply be left unchanged.
>>> Consequently, in the interests of simplicity, the 'as' clause is not
>>> included in this proposal.  A subsequent Python version can add this without
>>> breaking any existing code, as 'as' is already a keyword.
>> We can't defer this one - if we don't implement it now, we should
>> reject it as a future addition. The reason we can't defer it is
>> [ chomped for brevity ]
>>
>> So I think it makes more sense to reject this subproposal outright -
>> it makes the change more complex and make the handling of the common
>> case worse, for the sake of something that will almost never be an
>> appropriate thing to do.
Thanks for looking into this Nick.
I confess I don't entirely understand the technical argument (my 
understanding breaks down at "the subexpressions can't see the class 
level variables", but I don't want to waste anybody's time expecting an 
explanation, I can always look into it myself) but I accept that there 
is a good reason for disallowing 'as' and its usage would be rare, so I 
will (slightly regretfully) wave it goodbye.

>
>
> So, if it is to be rejected, I'd say it's on the technical grounds
> that it would require a closure in CPython, and that a closure is
> incompatible with the current proposal. Does that sound right?
It does to me FWIW.
>
> (It's also not a huge loss, since it's almost unused. But it's an
> incompatibility between statement and expression form.)
>
> ChrisA
Assuming the PEP is accepted (not a trivial assumption!)  I hope that at 
some stage allowing multiple except clauses (to trap different 
exceptions raised by the original expression) will be reinstated.  But I 
have to accept that it would be rarely used.

To my mind the real unsung hero of this story is the existing "try ... 
except ... finally" syntax and its flexibility.  In my code base there 
were a few hundred of these, but just over a dozen where the new syntax 
would be appropriate.  (Hope I'm not starting to argue against the PEP!)
Rob Cliffe
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/rob.cliffe%40btinternet.com
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2247 / Virus Database: 3705/6611 - Release Date: 02/20/14
>
>