<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 5, 2014 at 4:28 PM, Chris Angelico <span dir="ltr"><<a href="mailto:rosuav@gmail.com" target="_blank">rosuav@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On Thu, Mar 6, 2014 at 7:57 AM, Thomas Wouters <<a href="mailto:thomas@python.org">thomas@python.org</a>> wrote:<br>
</div><div class="">> All in all I believe I will continue to prefer specific methods for specific<br>
> use-cases; I'm -0 on the idea of an except-expression, -0 on the syntax with<br>
> the mandatory parentheses around the whole thing (and so far -1 on any of<br>
> the other suggested forms.) I can see the attractiveness, but frankly, all<br>
> the suggested changes to the stdlib fall in two categories: easier to<br>
> express (and narrower in its exception handling) with e.g. dict.get for the<br>
> trivial ones, or much better written out using temporary variables for the<br>
> complex ones. As soon as an except-expression has trouble fitting on two<br>
> lines it becomes an unsightly mess; it no longer becomes obvious what it<br>
> does from a glance. Not having except-expr may mean we keep adding methods<br>
> (with different names, and slightly different semantics) to cover specific<br>
> use-cases of specific types, but I can live with that.<br>
<br>
</div>Most of those concerns could also be aimed at the if/else expression.<br></blockquote><div><br></div><div>And I did :) But the if-else expression had a single thing going for it, the thing that landed the actual feature: it prevents people from using buggy alternatives in the quest for short code, the and-or trick. You may remember that Guido initially rejected the if-else expression, until he realized people were going to use something like it whether he liked it or not. The except-expression has a different issue: people catching exceptions too broadly. I don't believe that's as big a problem, nor is it as subtly wrong. And the except-expression doesn't solve _all_ such issues, just a very small subset. It's just another thing to learn when you're new, and just another thing to consider when reviewing code. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
There are definitely places that do not merit its use, but that<br>
doesn't mean the feature is a bad one. The PEP has a number of<br>
examples that fit quite happily on a single line, and it's those that<br>
I'm advocating. We have comprehensions, genexps, etc, etc, all (or at<br>
least most) of which can be written out in some form of long-hand, and<br>
it's usually better to use the short-hand - it's not just laziness,<br>
it's expressiveness.<br></blockquote><div><br></div><div>It's not a question of it being expressive, it's a question of it being worth separate syntax. I don't think it's worth syntax.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Speaking of the PEP, if someone could apply the latest changes, I<br>
think it's pretty much ready for pronouncement. Thanks! <br></blockquote><div><br></div><div>PEP update pushed (changeset 59653081cdf6.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Content:<br>
<a href="https://raw.github.com/Rosuav/ExceptExpr/master/pep-0463.txt" target="_blank">https://raw.github.com/Rosuav/ExceptExpr/master/pep-0463.txt</a><br>
<br>
Diff from current peps repo:<br>
<br>
diff -r 2cf89e9e50a3 pep-0463.txt<br>
--- a/pep-0463.txt Tue Mar 04 18:47:44 2014 -0800<br>
+++ b/pep-0463.txt Thu Mar 06 11:12:44 2014 +1100<br>
@@ -250,7 +250,8 @@<br>
alternatives listed above must (by the nature of functions) evaluate their<br>
default values eagerly. The preferred form, using the colon, parallels<br>
try/except by using "except exception_list:", and parallels lambda by having<br>
-"keyword name_list: subexpression". Using the arrow introduces a token many<br>
+"keyword name_list: subexpression"; it also can be read as mapping Exception<br>
+to the default value, dict-style. Using the arrow introduces a token many<br>
programmers will not be familiar with, and which currently has no similar<br>
meaning, but is otherwise quite readable. The English word "pass" has a<br>
vaguely similar meaning (consider the common usage "pass by value/reference"<br>
@@ -271,6 +272,18 @@<br>
Using the preferred order, subexpressions will always be evaluated from<br>
left to right, no matter how the syntax is nested.<br>
<br>
+Keeping the existing notation, but shifting the mandatory parentheses, we<br>
+have the following suggestion::<br>
+<br>
+ value = expr except (Exception: default)<br>
+ value = expr except(Exception: default)<br>
+<br>
+This is reminiscent of a function call, or a dict initializer. The colon<br>
+cannot be confused with introducing a suite, but on the other hand, the new<br>
+syntax guarantees lazy evaluation, which a dict does not. The potential<br>
+to reduce confusion is considered unjustified by the corresponding potential<br>
+to increase it.<br>
+<br>
<br>
Example usage<br>
=============<br>
@@ -854,6 +867,32 @@<br>
expression to achieve this.<br>
<br>
<br>
+Common objections<br>
+=================<br>
+<br>
+Colons always introduce suites<br>
+------------------------------<br>
+<br>
+While it is true that many of Python's syntactic elements use the colon to<br>
+introduce a statement suite (if, while, with, for, etcetera), this is not<br>
+by any means the sole use of the colon. Currently, Python syntax includes<br>
+four cases where a colon introduces a subexpression:<br>
+<br>
+* dict display - { ... key:value ... }<br>
+* slice notation - [start:stop:step]<br>
+* function definition - parameter : annotation<br>
+* lambda - arg list: return value<br>
+<br>
+This proposal simply adds a fifth:<br>
+<br>
+* except-expression - exception list: result<br>
+<br>
+Style guides and PEP 8 should recommend not having the colon at the end of<br>
+a wrapped line, which could potentially look like the introduction of a<br>
+suite, but instead advocate wrapping before the exception list, keeping the<br>
+colon clearly between two expressions.<br>
+<br>
+<br>
Copyright<br>
=========<br>
<br>
ChrisA<br>
<div class=""><div class="h5">_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/thomas%40python.org" target="_blank">https://mail.python.org/mailman/options/python-dev/thomas%40python.org</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Thomas Wouters <<a href="mailto:thomas@python.org" target="_blank">thomas@python.org</a>><br><br>Hi! I'm an email virus! Think twice before sending your email to help me spread!
</div></div>