From 920bced275f5f7f5919f45d06e823421f84e2273 Mon Sep 17 00:00:00 2001 From: Nick Coghlan Date: Wed, 21 Jul 2010 22:11:04 +0000 Subject: [PATCH] Fix some minor typos, add notes on topics not yet covered and point out that the most likely outcome for this PEP is eventual rejection --- pep-3150.txt | 53 +++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 46 insertions(+), 7 deletions(-) diff --git a/pep-3150.txt b/pep-3150.txt index 6943153bd..649d362df 100644 --- a/pep-3150.txt +++ b/pep-3150.txt @@ -36,7 +36,35 @@ This PEP is currently deferred at least until the language moratorium (PEP 3003) is officially lifted by Guido. Even after that, it will require input from at least the four major Python implementations (CPython, PyPy, Jython, IronPython) on the feasibility of implementing -the proposed semantics to get it moving again. +the proposed semantics to get it moving again. Input from related +projects with a vested interest in Python's syntax (e.g. Cython) will +also be valuable. + +That said, if a decision on acceptance or rejection had to be made +immediately, rejection would be far more likely. Unlike the previous +major syntax addition to Python (PEP 343's ``with`` statement), this +PEP has no "killer application" of code that is clearly and obviously +improved through the use of the new syntax. The ``with`` statement (in +conjunction with the generator enhancements in PEP 342) allowed +exception handling to be factored out into context managers in a way +that had never before been possible. Code using the new statement was +not only easier to read, but much easier to write correctly in the +first place. + +In the case of this PEP. however, the "Two Ways to Do It" objection is a +strong one. While the ability to break out subexpresions of a statement +without having to worry about name clashes with the rest of a +function or script and without distracting from the operation that is +the ultimate aim of the statement is potentially nice to have as a +language feature, it doesn't really provide significant expressive power +over and above what is already possible by assigning subexpressions to +ordinary local variables before the statement of interest. In particular, +explaining to new Python programmers when it is best to use a ``given`` +clause and when to use normal local variables is likely to be challenging +and an unnecessary distraction. + +"It might be kinda, sorta, nice to have, sometimes" really isn't a strong +argument for a new syntactic construct (particularly one this complicated). Proposal ======== @@ -174,7 +202,7 @@ Current:: New:: expr_stmt: testlist_star_expr (augassign (yield_expr|testlist) | - ('=' (yield_expr|testlist_star_expr))*) [where_clause] + ('=' (yield_expr|testlist_star_expr))*) [given_clause] del_stmt: 'del' exprlist [given_clause] return_stmt: 'return' [testlist] [given_clause] yield_stmt: yield_expr [given_clause] @@ -190,7 +218,7 @@ rather than as a new kind of compound statement in order to avoid creating an ambiguity in the grammar. It is applied only to the specific elements listed so that nonsense like the following is disallowed:: - pass where: + pass given: a = b = 1 However, even this is inadequate, as it creates problems for the definition @@ -230,11 +258,11 @@ Common Objections * Two Ways To Do It: a lot of code may now be written with values defined either before the expression where they are used or - afterwards in a ``where`` clause, creating two ways to do it, + afterwards in a ``given`` clause, creating two ways to do it, without an obvious way of choosing between them. -* Out of Order Execution: the ``where`` clause makes execution - jump around a little strangely, as the body of the ``where`` +* Out of Order Execution: the ``given`` clause makes execution + jump around a little strangely, as the body of the ``given`` clause is executed before the simple statement in the clause header. The closest any other part of Python comes to this is the out of order evaluation in list comprehensions, @@ -348,13 +376,24 @@ However, as noted in the abstract, an actual implementation of this idea has never been tried. -Reference implementation +Reference Implementation ======================== None as yet. If you want a crash course in Python namespace semantics and code compilation, feel free to try ;) +TO-DO +===== + +* Mention two-suite in-order variants (and explain why they're even more + pointless than the specific idea in the PEP) +* Mention PEP 359 and possible uses for locals() in the ``given`` clause +* Describe the expected semantics of ``break``, ``continue``, ``return`` + and ``yield`` in a ``given`` clause (i.e. syntax errors at the clause + level, but allowed inside the appropriate compound statements) + + References ==========