fixed list indentation; status: Draft is correct

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
@@ -105,9 +105,9 @@ is equivalent to::
        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::
 
@@ -117,8 +117,8 @@ change:
 
          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.
 
@@ -134,16 +134,17 @@ 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.
+   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::
 
@@ -180,10 +181,11 @@ captured.  They may still change if they are mutable, for example::
 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 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]
 
@@ -201,12 +203,12 @@ 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.
+   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.
 
 
 Reduction Functions
@@ -222,18 +224,18 @@ 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.