Minor editorial clean ups:

- conform the headers
    - `standard' paragraph wrapping (i.e. how the Editor's editor
      wraps 'em :)
    - move the URL for the patch to the (new) References section
    - added reference to PEP 201

Tim, should this be marked Accepted now?
This commit is contained in:
Barry Warsaw 2000-08-23 05:19:21 +00:00
parent 236ed3e71a
commit 0c47bb2a51
1 changed files with 34 additions and 30 deletions

View File

@ -1,31 +1,32 @@
PEP: 202
Title: List Comprehensions
Version: $Revision$
Owner: tpeters@beopen.com (Tim Peters)
Author: tpeters@beopen.com (Tim Peters)
Status: Draft
Type: Standards Track
Python-Version: 2.0
Status: Incomplete
Created: 13-Jul-2000
Post-History:
Introduction
This PEP describes a proposed syntactical extension to Python, list
comprehensions.
This PEP describes a proposed syntactical extension to Python,
list comprehensions.
The Proposed Solution
It is proposed to allow conditional construction of list literals using
for and if clauses. They would nest in the same way for loops and if
statements nest now.
It is proposed to allow conditional construction of list literals
using for and if clauses. They would nest in the same way for
loops and if statements nest now.
Rationale
List comprehensions provide a more concise way to create lists in
situations where map() and filter() and/or nested loops would currently
be used.
situations where map() and filter() and/or nested loops would
currently be used.
Examples
@ -59,11 +60,7 @@ Examples
Reference Implementation
Please refer to
https://sourceforge.net/patch/?func=detailpatch&patch_id=100654&group_id=5470
for a patch that adds list comprehensions to Python.
SourceForge contains a patch that adds list comprehensions to Python[1].
BDFL Pronouncements
@ -74,19 +71,19 @@ BDFL Pronouncements
- The syntax proposed above is the Right One.
- The form [x, y for ...] should be disallowed; one should be
required to write [(x, y) for ...].
required to write [(x, y) for ...].
- The form [... for x... for y...] nests, with the last index
varying fastest, just like nested for loops.
varying fastest, just like nested for loops.
Open Issues
Syntax
Several people proposed connecting or separating syntax between the
various clauses, for example, requiring a semicolon between them to
set them apart:
Several people proposed connecting or separating syntax
between the various clauses, for example, requiring a
semicolon between them to set them apart:
[i,f; for i in nums; for f in fruit; if f[0]=="P"; if i%2==1]
@ -113,18 +110,25 @@ Open Issues
map(None, nums, fruit)
It's not clear that this is necessary. The newly proposed zip()
builtin takes care of that case.
It's not clear that this is necessary. The newly proposed
zip() builtin[2] takes care of that case.
Stability of the Implementation
The current reference implementation is simply an adaptation of Greg
Ewing's original demonstration of the concept. Other than tracking
changes to the source code to keep it a valid patch, reindenting the
code and switching to function prototypes, nothing has been done to
it. This obviously raises some questions about how stable the code
is. It has not had a lot of exercise, though the patch does include
a few test cases.
The current reference implementation is simply an adaptation
of Greg Ewing's original demonstration of the concept. Other
than tracking changes to the source code to keep it a valid
patch, reindenting the code and switching to function
prototypes, nothing has been done to it. This obviously
raises some questions about how stable the code is. It has
not had a lot of exercise, though the patch does include a few
test cases.
References
[1] https://sourceforge.net/patch/?func=detailpatch&patch_id=100654&group_id=5470
[2] Lockstep Iteration, pep-0201.txt
Local Variables: