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. 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. Speaking of the PEP, if someone could apply the latest changes, I think it's pretty much ready for pronouncement. Thanks! 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/archive%40mail-archive.com
