[Python-checkins] peps: Initial set of Python Enhancement Proposals
georg.brandl
python-checkins at python.org
Wed Mar 23 21:21:39 CET 2011
http://hg.python.org/peps/rev/052748287b89
changeset: 0:052748287b89
user: Barry Warsaw <barry at python.org>
date: Thu Jul 13 06:33:08 2000 +0000
summary:
Initial set of Python Enhancement Proposals
files:
pep-0000.txt | 31 ++++
pep-0001.txt | 11 +
pep-0200.txt | 21 +++
pep-0201.txt | 247 +++++++++++++++++++++++++++++++++++++++
pep-0202.txt | 12 +
pep-0203.txt | 12 +
6 files changed, 334 insertions(+), 0 deletions(-)
diff --git a/pep-0000.txt b/pep-0000.txt
new file mode 100644
--- /dev/null
+++ b/pep-0000.txt
@@ -0,0 +1,31 @@
+PEP: 0
+Title: Index of Python Enhancement Proposals (PEPs)
+Version: $Revision$
+Owner: bwarsaw at beopen.com (Barry A. Warsaw)
+Status: Active
+
+
+Introduction
+
+ The PEP contains the index of all Python Enhancement Proposals,
+ known as PEPs. PEP numbers are assigned by the PEP Editor, and
+ once assigned are never changed.
+
+Index
+
+ num filename title
+ ---- -------- -----
+ 0 pep-0000.txt Index of Python Enhance Proposals
+ 1 pep-0001.txt PEP Guidelines
+
+ 200 pep-0200.txt Python 2.0 Release Schedule
+ 201 pep-0201.txt Parallel Iteration
+ 202 pep-0202.txt List Comprehensions
+ 203 pep-0203.txt Augmented Assignments
+
+
+
+Local Variables:
+mode: indented-text
+indent-tabs-mode: nil
+End:
diff --git a/pep-0001.txt b/pep-0001.txt
new file mode 100644
--- /dev/null
+++ b/pep-0001.txt
@@ -0,0 +1,11 @@
+PEP: 1
+Title: PEP Guidelines
+Version: $Revision$
+Owner: bwarsaw at beopen.com (Barry A. Warsaw)
+Status: Incomplete
+
+
+Local Variables:
+mode: indented-text
+indent-tabs-mode: nil
+End:
diff --git a/pep-0200.txt b/pep-0200.txt
new file mode 100644
--- /dev/null
+++ b/pep-0200.txt
@@ -0,0 +1,21 @@
+PEP: 200
+Title: Python 2.0 Release Schedule
+Version: $Revision$
+Owner: bwarsaw at beopen.com (Barry A. Warsaw)
+Python-Version: 2.0
+Status: Incomplete
+
+Introduction
+
+ This PEP describes the Python 2.0 release schedule, tracking the
+ status and ownership of the major new features, summarizes
+ discussions held in mailing list forums, and provides URLs for
+ further information, patches, and other outstanding issues. The
+ CVS revision history of this file contains the definitive
+ historical record.
+
+
+Local Variables:
+mode: indented-text
+indent-tabs-mode: nil
+End:
diff --git a/pep-0201.txt b/pep-0201.txt
new file mode 100644
--- /dev/null
+++ b/pep-0201.txt
@@ -0,0 +1,247 @@
+PEP: 201
+Title: Parallel Iteration
+Version: $Revision$
+Owner: bwarsaw at beopen.com (Barry A. Warsaw)
+Python-Version: 2.0
+Status: Draft
+
+
+
+Introduction
+
+ This PEP describes the `parallel iteration' proposal for Python
+ 2.0, previously known as `parallel for loops'. This PEP tracks
+ the status and ownership of this feature, slated for introduction
+ in Python 2.0. It contains a description of the feature and
+ outlines changes necessary to support the feature. This PEP
+ summarizes discussions held in mailing list forums, and provides
+ URLs for further information, where appropriate. The CVS revision
+ history of this file contains the definitive historical record.
+
+
+
+Standard For-Loops
+
+ Motivation for this feature has its roots in a concept described
+ as `parallel for loops'. A standard for-loop in Python iterates
+ over every element in the sequence until the sequence is
+ exhausted. The for-loop can also be explicitly exited with a
+ `break' statement, and for-loops can have else: clauses, but these
+ is has no bearing on this PEP.
+
+ For-loops can iterate over built-in types such as lists and
+ tuples, but they can also iterate over instance types that conform
+ to an informal sequence protocol. This protocol states that the
+ instance should implement the __getitem__() method, expecting a
+ monotonically increasing index starting at 0, and this method
+ should raise an IndexError when the sequence is exhausted. This
+ protocol is current undocumented -- a defect in Python's
+ documentation hopefully soon corrected.
+
+ For loops are described in the language reference manual here
+ http://www.python.org/doc/devel/ref/for.html
+
+ An example for-loop
+
+ >>> for i in (1, 2, 3): print i
+ ...
+ 1
+ 2
+ 3
+
+ In this example, the variable `i' is called the `target', and is
+ assigned the next element of the list, each time through the loop.
+
+
+
+Parallel For-Loops
+
+ Parallel for-loops are non-nested iterations over two or more
+ sequences, such that at each pass through the loop, one element
+ from each sequence is taken to compose the target. This behavior
+ can already be accomplished in Python through the use of the map()
+ built-in function:
+
+ >>> a = (1, 2, 3)
+ >>> b = (4, 5, 6)
+ >>> for i in map(None, a, b): print i
+ ...
+ (1, 4)
+ (2, 5)
+ (3, 6)
+
+ Here, map() returns a list of N-tuples, where N is the number of
+ sequences in map()'s argument list (after the initial `None').
+ Each tuple is constructed of the i-th elements from each of the
+ argument lists, specifically in this example:
+
+ >>> map(None, a, b)
+ [(1, 4), (2, 5), (3, 6)]
+
+ The for-loop simply iterates over this list as normal.
+
+ While the map() idiom is a common one in Python, it has several
+ disadvantages:
+
+ - It is non-obvious to programmers without a functional
+ programming background.
+
+ - The use of the magic `None' first argument is non-obvious.
+
+ - Its has arbitrary, often unintended, and inflexible semantics
+ when the lists are not of the same length: the shorter sequences
+ are padded with `None'.
+
+ >>> c = (4, 5, 6, 7)
+ >>> map(None, a, c)
+ [(1, 4), (2, 5), (3, 6), (None, 7)]
+
+ For these reasons, several proposals were floated in the Python
+ 2.0 beta time frame for providing a better spelling of parallel
+ for-loops. The initial proposals centered around syntactic
+ changes to the for statement, but conflicts and problems with the
+ syntax were unresolvable, especially when parallel for-loops were
+ combined with another proposed feature called `list
+ comprehensions' (see pep-0202.txt).
+
+
+
+The Proposed Solution
+
+ The proposed solution is to introduce a new built-in sequence
+ generator function, available in the __builtin__ module. This
+ function is to be called `marry' and has the following signature:
+
+ marry(seqa, [seqb, [...]], [pad=<value>])
+
+ marry() takes one or more sequences and weaves their elements
+ together, just as map(None, ...) does with sequences of equal
+ length. The optional keyword argument `pad', if supplied, is a
+ value used to pad all shorter sequences to the length of the
+ longest sequence. If `pad' is omitted, then weaving stops when
+ the shortest sequence is exhausted.
+
+ It is not possible to pad short lists with different pad values,
+ nor will marry() ever raise an exception with lists of different
+ lengths. To accomplish both of these, the sequences must be
+ checked and processed before the call to marry().
+
+
+
+Lazy Execution
+
+ For performance purposes, marry() does not construct the list of
+ tuples immediately. Instead it instantiates an object that
+ implements a __getitem__() method and conforms to the informal
+ for-loop protocol. This method constructs the individual tuples
+ on demand.
+
+
+
+Examples
+
+ Here are some examples, based on the reference implementation
+ below.
+
+ >>> a = (1, 2, 3, 4)
+ >>> b = (5, 6, 7, 8)
+ >>> c = (9, 10, 11)
+ >>> d = (12, 13)
+
+ >>> marry(a, b)
+ [(1, 5), (2, 6), (3, 7), (4, 8)]
+
+ >>> marry(a, d)
+ [(1, 12), (2, 13)]
+
+ >>> marry(a, d, pad=0)
+ [(1, 12), (2, 13), (3, 0), (4, 0)]
+
+ >>> marry(a, d, pid=0)
+ Traceback (most recent call last):
+ File "<stdin>", line 1, in ?
+ File "/usr/tmp/python-iKAOxR", line 11, in marry
+ TypeError: unexpected keyword arguments
+
+ >>> marry(a, b, c, d)
+ [(1, 5, 9, 12), (2, 6, 10, 13)]
+
+ >>> marry(a, b, c, d, pad=None)
+ [(1, 5, 9, 12), (2, 6, 10, 13), (3, 7, 11, None), (4, 8, None, None)]
+ >>> map(None, a, b, c, d)
+ [(1, 5, 9, 12), (2, 6, 10, 13), (3, 7, 11, None), (4, 8, None, None)]
+
+
+
+Reference Implementation
+
+ Here is a reference implementation, in Python of the marry()
+ built-in function and helper class. These would ultimately be
+ replaced by equivalent C code.
+
+ class _Marriage:
+ def __init__(self, args, kws):
+ self.__padgiven = 0
+ if kws.has_key('pad'):
+ self.__padgiven = 1
+ self.__pad = kws['pad']
+ del kws['pad']
+ if kws:
+ raise TypeError('unexpected keyword arguments')
+ self.__sequences = args
+ self.__seqlen = len(args)
+
+ def __getitem__(self, i):
+ ret = []
+ exhausted = 0
+ for s in self.__sequences:
+ try:
+ ret.append(s[i])
+ except IndexError:
+ if not self.__padgiven:
+ raise
+ exhausted = exhausted + 1
+ if exhausted == self.__seqlen:
+ raise
+ ret.append(self.__pad)
+ return tuple(ret)
+
+ def __str__(self):
+ ret = []
+ i = 0
+ while 1:
+ try:
+ ret.append(self[i])
+ except IndexError:
+ break
+ i = i + 1
+ return str(ret)
+ __repr__ = __str__
+
+
+ def marry(*args, **kws):
+ return _Marriage(args, kws)
+
+
+
+Open Issues
+
+ What should "marry(a)" do?
+
+ Given a = (1, 2, 3), should marry(a) return [(1,), (2,), (3,)] or
+ should it return [1, 2, 3]? The first is more consistent with the
+ description given above, while the latter is what map(None, a)
+ does, and may be more consistent with user expectation.
+
+ The latter interpretation requires special casing, which is not
+ present in the reference implementation. It returns
+
+ >>> marry(a)
+ [(1,), (2,), (3,), (4,)]
+
+
+
+Local Variables:
+mode: indented-text
+indent-tabs-mode: nil
+End:
diff --git a/pep-0202.txt b/pep-0202.txt
new file mode 100644
--- /dev/null
+++ b/pep-0202.txt
@@ -0,0 +1,12 @@
+PEP: 202
+Title: List Comprehensions
+Version: $Revision$
+Owner: bwarsaw at beopen.com (Barry A. Warsaw)
+Python-Version: 2.0
+Status: Incomplete
+
+
+Local Variables:
+mode: indented-text
+indent-tabs-mode: nil
+End:
diff --git a/pep-0203.txt b/pep-0203.txt
new file mode 100644
--- /dev/null
+++ b/pep-0203.txt
@@ -0,0 +1,12 @@
+PEP: 203
+Title: Augmented Assignments
+Version: $Revision$
+Owner: bwarsaw at beopen.com (Barry A. Warsaw)
+Python-Version: 2.0
+Status: Incomplete
+
+
+Local Variables:
+mode: indented-text
+indent-tabs-mode: nil
+End:
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list