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