From 326a56a0f33af907c48e37f11c22046b95b7c58e Mon Sep 17 00:00:00 2001 From: David Goodger Date: Thu, 23 Oct 2003 12:51:30 +0000 Subject: [PATCH] fixed list indentation; status: Draft is correct --- pep-0289.txt | 170 ++++++++++++++++++++++++++------------------------- 1 file changed, 86 insertions(+), 84 deletions(-) diff --git a/pep-0289.txt b/pep-0289.txt index 5c6619689..836012af7 100644 --- a/pep-0289.txt +++ b/pep-0289.txt @@ -3,7 +3,7 @@ Title: Generator Expressions Version: $Revision$ Last-Modified: $Date$ Author: python@rcn.com (Raymond D. Hettinger) -Status: Active +Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 30-Jan-2002 @@ -91,122 +91,124 @@ c.l.py. The Python Reference Manual should contain a 100% exact semantic and syntactic specification.) 1. The semantics of a generator expression are equivalent to creating -an anonymous generator function and calling it. For example:: + an anonymous generator function and calling it. For example:: - g = (x**2 for x in range(10)) - print g.next() + g = (x**2 for x in range(10)) + print g.next() -is equivalent to:: + is equivalent to:: - def __gen(): - for x in range(10): - yield x**2 - g = __gen() - print g.next() + def __gen(): + for x in range(10): + yield x**2 + g = __gen() + print g.next() 2. The syntax requires that a generator expression always needs to be -directly inside a set of parentheses and cannot have a comma on either -side. With reference to the file Grammar/Grammar in CVS, two rules -change: + directly inside a set of parentheses and cannot have a comma on + either side. With reference to the file Grammar/Grammar in CVS, + two rules change: - a) The rule:: + a) The rule:: - atom: '(' [testlist] ')' + atom: '(' [testlist] ')' - changes to:: + changes to:: - atom: '(' [listmaker1] ')' + atom: '(' [listmaker1] ')' - where listmaker1 is almost the same as listmaker, but only allows - a single test after 'for' ... 'in'. + where listmaker1 is almost the same as listmaker, but only + allows a single test after 'for' ... 'in'. - b) The rule for arglist needs similar changes. + b) The rule for arglist needs similar changes. -This means that you can write:: + This means that you can write:: - sum(x**2 for x in range(10)) + sum(x**2 for x in range(10)) -but you would have to write:: + but you would have to write:: - reduce(operator.add, (x**2 for x in range(10))) + reduce(operator.add, (x**2 for x in range(10))) -and also:: + and also:: - g = (x**2 for i in range(10)) + g = (x**2 for i in range(10)) -i.e. if a function call has a single positional argument, it can be a -generator expression without extra parentheses, but in all other cases -you have to parenthesize it. + i.e. if a function call has a single positional argument, it can be + a generator expression without extra parentheses, but in all other + cases you have to parenthesize it. 3. The loop variable (if it is a simple variable or a tuple of simple -variables) is not exposed to the surrounding function. This facilates -the implementation and makes typical use cases more reliable. In some -future version of Python, list comprehensions will also hide the -induction variable from the surrounding code (and, in Py2.4, warnings -will be issued for code accessing the induction variable). + variables) is not exposed to the surrounding function. This + facilates the implementation and makes typical use cases more + reliable. In some future version of Python, list comprehensions + will also hide the induction variable from the surrounding code + (and, in Py2.4, warnings will be issued for code accessing the + induction variable). -For example:: + For example:: - x = "hello" - y = list(x for x in "abc") - print x # prints "hello", not "c" + x = "hello" + y = list(x for x in "abc") + print x # prints "hello", not "c" -(Loop variables may also use constructs like x[i] or x.a; this form -may be deprecated.) + (Loop variables may also use constructs like x[i] or x.a; this form + may be deprecated.) 4. All free variable bindings are captured at the time this function -is defined, and passed into it using default argument values. For -example:: + is defined, and passed into it using default argument values. For + example:: - x = 0 - g = (x for c in "abc") # x is not the loop variable! - x = 1 - print g.next() # prints 0 (captured x), not 1 (current x) + x = 0 + g = (x for c in "abc") # x is not the loop variable! + x = 1 + print g.next() # prints 0 (captured x), not 1 (current x) -This behavior of free variables is almost always what you want when -the generator expression is evaluated at a later point than its -definition. In fact, to date, no examples have been found of code -where it would be better to use the execution-time instead of the -definition-time value of a free variable. + This behavior of free variables is almost always what you want when + the generator expression is evaluated at a later point than its + definition. In fact, to date, no examples have been found of code + where it would be better to use the execution-time instead of the + definition-time value of a free variable. -Note that free variables aren't copied, only their binding is -captured. They may still change if they are mutable, for example:: + Note that free variables aren't copied, only their binding is + captured. They may still change if they are mutable, for example:: - x = [] - g = (x for c in "abc") - x.append(1) - print g.next() # prints [1], not [] + x = [] + g = (x for c in "abc") + x.append(1) + print g.next() # prints [1], not [] 5. List comprehensions will remain unchanged. For example:: - [x for x in S] # This is a list comprehension. - [(x for x in S)] # This is a list containing one generator expression. + [x for x in S] # This is a list comprehension. + [(x for x in S)] # This is a list containing one generator + # expression. -Unfortunately, there is currently a slight syntactic difference. The -expression:: + Unfortunately, there is currently a slight syntactic difference. + The expression:: - [x for x in 1, 2, 3] + [x for x in 1, 2, 3] -is legal, meaning:: + is legal, meaning:: - [x for x in (1, 2, 3)] + [x for x in (1, 2, 3)] -But generator expressions will not allow the former version:: + But generator expressions will not allow the former version:: - (x for x in 1, 2, 3) + (x for x in 1, 2, 3) -is illegal. + is illegal. -The former list comprehension syntax will become illegal in Python -3.0, and should be deprecated in Python 2.4 and beyond. + The former list comprehension syntax will become illegal in Python + 3.0, and should be deprecated in Python 2.4 and beyond. -List comprehensions also "leak" their loop variable into the -surrounding scope. This will also change in Python 3.0, so that the -semantic definition of a list comprehension in Python 3.0 will be -equivalent to list(). Python 2.4 and beyond -should issue a deprecation warning if a list comprehension's loop -variable has the same name as a variable used in the immediately -surrounding scope. + List comprehensions also "leak" their loop variable into the + surrounding scope. This will also change in Python 3.0, so that + the semantic definition of a list comprehension in Python 3.0 will + be equivalent to list(). Python 2.4 and + beyond should issue a deprecation warning if a list comprehension's + loop variable has the same name as a variable used in the + immediately surrounding scope. Reduction Functions @@ -215,25 +217,25 @@ Reduction Functions The utility of generator expressions is greatly enhanced when combined with reduction functions like sum(), min(), and max(). Separate proposals are forthcoming that recommend several new accumulation -functions possibly including: product(), average(), alltrue(), +functions possibly including: product(), average(), alltrue(), anytrue(), nlargest(), nsmallest(). Acknowledgements ================ -* Raymond Hettinger first proposed the idea of "generator comprehensions" - in January 2002. +* Raymond Hettinger first proposed the idea of "generator + comprehensions" in January 2002. * Peter Norvig resurrected the discussion in his proposal for Accumulation Displays. -* Alex Martelli provided critical measurements that proved the performance - benefits of generator expressions. He also provided strong arguments - that they were a desirable thing to have. +* Alex Martelli provided critical measurements that proved the + performance benefits of generator expressions. He also provided + strong arguments that they were a desirable thing to have. -* Samuele Pedroni provided the example of late binding. - Various contributors have made arguments for and against late binding. +* Samuele Pedroni provided the example of late binding. Various + contributors have made arguments for and against late binding. * Phillip Eby suggested "iterator expressions" as the name.