PEP 403/3150 tweaks based on python-ideas discission

pep-0403.txt

@@ -30,7 +30,8 @@ only to the statement in the ``@in`` clause.
 
 This PEP is based heavily on many of the ideas in PEP 3150 (Statement Local
 Namespaces) so some elements of the rationale will be familiar to readers of
-that PEP. That PEP has now been withdrawn in favour of this one.
+that PEP. Both PEPs remain deferred for the time being, primarily due to the
+lack of compelling real world use cases in either PEP.
 
 
 Basic Examples
@@ -201,7 +202,7 @@ decorators, but covering a broader set of applications.
 Relation to PEP 3150
 --------------------
 
-PEP 3150 (Statement Local Namespaces) described its primary motivation
+PEP 3150 (Statement Local Namespaces) describes its primary motivation
 as being to elevate ordinary assignment statements to be on par with ``class``
 and ``def`` statements where the name of the item to be defined is presented
 to the reader in advance of the details of how the value of that item is
@@ -210,13 +211,13 @@ the simple name binding of a standard function definition to be replaced
 with something else (like assigning the result of the function to a value).
 
 Despite having the same author, the two PEPs are in direct competition with
-each other. This PEP represents a minimalist approach that attempts to
-achieve useful functionality with a minimum of change from the status quo.
-PEP 3150 instead aims for a more flexible standalone statement design, which
-requires a larger degree of change to the language.
+each other. PEP 403 represents a minimalist approach that attempts to achieve
+useful functionality with a minimum of change from the status quo. This PEP
+instead aims for a more flexible standalone statement design, which requires
+a larger degree of change to the language.
 
-Note that where this PEP is better suited to explaining the behaviour of
-generator expressions correctly, PEP 3150 is better able to explain the
+Note that where PEP 403 is better suited to explaining the behaviour of
+generator expressions correctly, this PEP is better able to explain the
 behaviour of decorator clauses in general. Both PEPs support adequate
 explanations for the semantics of container comprehensions.
 

pep-3150.txt

@@ -100,7 +100,7 @@ binding operations in the header line::
    # Explicit early binding via given clause
    seq = []
    for i in range(10):
-       seq.append(.f) given i=i in:
+       seq.append(?.f) given i=i in:
            def f():
                return i
    assert [f() for f in seq] == list(range(10))
@@ -171,6 +171,12 @@ New::
 assignment and augmented assignment in addition to simple expression
 statements)
 
+.. note::
+   These proposed grammar changes don't yet cover the forward reference
+   expression syntax for accessing names defined in the statement local
+   namespace.
+
+
 The new clause is added as an optional element of the existing statements
 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
@@ -706,6 +712,14 @@ Rejected Alternatives
   naming the function before the statement that uses it means the code
   no longer matches the way the developer thinks about the problem at hand.
 
+* I've made some unpublished attempts to allow direct references to the
+  closure implicitly created by the ``given`` clause, while still retaining
+  the general structure of the syntax as defined in this PEP (For example,
+  allowing a subexpression like ``?given`` or ``:given`` to be used in
+  expressions to indicate a direct reference to the implied closure, thus
+  preventig it from being called automatically to create the local namespace).
+  All such attempts have appeared unattractive and confusing compared to
+  the simpler decorator-inspired proposal in PEP 403.
 
 Reference Implementation
 ========================