Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1:/tmp/cvs-serv16621
Modified Files:
pep-0289.txt
Log Message:
fixed list indentation; status: Draft is correct
Index: pep-0289.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0289.txt,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** pep-0289.txt 23 Oct 2003 08:10:05 -0000 1.6
--- pep-0289.txt 23 Oct 2003 12:51:30 -0000 1.7
***************
*** 4,8 ****
Last-Modified: $Date$
Author: python(a)rcn.com (Raymond D. Hettinger)
! Status: Active
Type: Standards Track
Content-Type: text/x-rst
--- 4,8 ----
Last-Modified: $Date$
Author: python(a)rcn.com (Raymond D. Hettinger)
! Status: Draft
Type: Standards Track
Content-Type: text/x-rst
***************
*** 92,211 ****
1. The semantics of a generator expression are equivalent to creating
! an anonymous generator function and calling it. For example::
! g = (x**2 for x in range(10))
! print g.next()
! is equivalent to::
! 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:
! a) The rule::
! atom: '(' [testlist] ')'
! changes to::
! atom: '(' [listmaker1] ')'
! 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.
! This means that you can write::
! sum(x**2 for x in range(10))
! but you would have to write::
! reduce(operator.add, (x**2 for x in range(10)))
! and also::
! 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.
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).
! For example::
! 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.)
4. All free variable bindings are captured at the time this function
! 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)
! 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::
! 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.
! Unfortunately, there is currently a slight syntactic difference. The
! expression::
! [x for x in 1, 2, 3]
! is legal, meaning::
! [x for x in (1, 2, 3)]
! But generator expressions will not allow the former version::
! (x for x in 1, 2, 3)
! is illegal.
! 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(<generator expression>). 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.
--- 92,213 ----
1. The semantics of a generator expression are equivalent to creating
! an anonymous generator function and calling it. For example::
! g = (x**2 for x in range(10))
! print g.next()
! is equivalent to::
! 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:
! a) The rule::
! atom: '(' [testlist] ')'
! changes to::
! atom: '(' [listmaker1] ')'
! 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.
! This means that you can write::
! sum(x**2 for x in range(10))
! but you would have to write::
! reduce(operator.add, (x**2 for x in range(10)))
! and also::
! 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.
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).
! For example::
! 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.)
4. All free variable bindings are captured at the time this function
! 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)
! 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::
! 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.
! Unfortunately, there is currently a slight syntactic difference.
! The expression::
! [x for x in 1, 2, 3]
! is legal, meaning::
! [x for x in (1, 2, 3)]
! But generator expressions will not allow the former version::
! (x for x in 1, 2, 3)
! is illegal.
! 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(<generator expression>). 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.
***************
*** 216,220 ****
with reduction functions like sum(), min(), and max(). Separate
proposals are forthcoming that recommend several new accumulation
! functions possibly including: product(), average(), alltrue(),
anytrue(), nlargest(), nsmallest().
--- 218,222 ----
with reduction functions like sum(), min(), and max(). Separate
proposals are forthcoming that recommend several new accumulation
! functions possibly including: product(), average(), alltrue(),
anytrue(), nlargest(), nsmallest().
***************
*** 223,238 ****
================
! * 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.
! * 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.
--- 225,240 ----
================
! * 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.
! * 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.
