From 90c3d99390aa8bc9ffd3f211c044bd9f95dc3b12 Mon Sep 17 00:00:00 2001 From: Nick Coghlan Date: Tue, 1 Jul 2014 14:02:16 +1000 Subject: [PATCH] PEP 403/3150 tweaks based on python-ideas discission --- pep-0403.txt | 17 +++++++++-------- pep-3150.txt | 16 +++++++++++++++- 2 files changed, 24 insertions(+), 9 deletions(-) diff --git a/pep-0403.txt b/pep-0403.txt index 3fa83333a..9a0740b36 100644 --- a/pep-0403.txt +++ b/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. diff --git a/pep-3150.txt b/pep-3150.txt index fb615f96f..008bdd6a1 100644 --- a/pep-3150.txt +++ b/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 ========================