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@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@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/rob.cliffe%40btinternet.c...
----- 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