[Python-checkins] r83044 - peps/trunk/pep-3150.txt

[nick.coghlan]

Author: nick.coghlan
Date: Thu Jul 22 00:11:04 2010
New Revision: 83044

Log:
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

Modified:
   peps/trunk/pep-3150.txt

Modified: peps/trunk/pep-3150.txt
==============================================================================
--- peps/trunk/pep-3150.txt	(original)
+++ peps/trunk/pep-3150.txt	Thu Jul 22 00:11:04 2010
@@ -36,7 +36,35 @@
 (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 @@
 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 @@
 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 @@
 
 * 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 @@
 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
 ==========