[Python-checkins] python/nondist/peps pep-0289.txt,1.6,1.7

Thu Oct 23 08:51:32 EDT 2003

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 at rcn.com (Raymond D. Hettinger)
! Status: Active
  Type: Standards Track
  Content-Type: text/x-rst
--- 4,8 ----
  Last-Modified: $Date$
  Author: python at 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.