[Python-Dev] PEP 463: Exception-catching expressions
rob.cliffe at btinternet.com
Fri Feb 21 15:22:34 CET 2014
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
>>> 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
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.)
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!)
> Python-Dev mailing list
> Python-Dev at python.org
> 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
More information about the Python-Dev