[Python-checkins] r55062 - peps/trunk/pep-0000.txt peps/trunk/pep-3132.txt

[georg.brandl]

Author: georg.brandl
Date: Tue May  1 23:42:23 2007
New Revision: 55062

Added:
   peps/trunk/pep-3132.txt
Modified:
   peps/trunk/pep-0000.txt
Log:
Add PEP 3132, "Extended Iterable Unpacking", by me.


Modified: peps/trunk/pep-0000.txt
==============================================================================
--- peps/trunk/pep-0000.txt	(original)
+++ peps/trunk/pep-0000.txt	Tue May  1 23:42:23 2007
@@ -131,6 +131,7 @@
  S  3129  Class Decorators                             Winter
  S  3130  Access to Current Module/Class/Function      Jewett
  S  3131  Supporting Non-ASCII Identifiers             von Löwis
+ S  3132  Extended Iterable Unpacking                  Brandl
  S  3141  A Type Hierarchy for Numbers                 Yasskin
 
  Finished PEPs (done, implemented in Subversion)
@@ -504,6 +505,7 @@
  S  3129  Class Decorators                             Winter
  S  3130  Access to Current Module/Class/Function      Jewett
  S  3131  Supporting Non-ASCII Identifiers             von Löwis
+ S  3132  Extended Iterable Unpacking                  Brandl
  S  3141  A Type Hierarchy for Numbers                 Yasskin
 
 

Added: peps/trunk/pep-3132.txt
==============================================================================
--- (empty file)
+++ peps/trunk/pep-3132.txt	Tue May  1 23:42:23 2007
@@ -0,0 +1,118 @@
+PEP: 3132
+Title: Extended Iterable Unpacking
+Version: $Revision$
+Last-Modified: $Date$
+Author: Georg Brandl <georg at python.org>
+Status: Draft
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 30-Apr-2007
+Python-Version: 3.0
+Post-History:
+
+
+Abstract
+========
+
+This PEP proposes a change to iterable unpacking syntax, allowing to
+specify a "catch-all" name which will be assigned a list of all items
+not assigned to a "regular" name.
+
+An example says more than a thousand words::
+
+    >>> a, *b, c = range(5)
+    >>> a
+    0
+    >>> c
+    4
+    >>> b
+    [1, 2, 3]
+
+
+Rationale
+=========
+
+Many algorithms require splitting a sequence in a "first, rest" pair.
+With the new syntax, ::
+
+    first, rest = seq[0], seq[1:]
+
+is replaced by the cleaner and probably more efficient::
+
+    first, *rest = seq
+
+For more complex unpacking patterns, the new syntax looks even
+cleaner, and the clumsy index handling is not necessary anymore.
+
+
+Specification
+=============
+
+A tuple (or list) on the left side of a simple assignment (unpacking
+is not defined for augmented assignment) may contain at most one
+expression prepended with a single asterisk.  For the rest of this
+section, the other expressions in the list are called "mandatory".
+
+Note that this also refers to tuples in implicit assignment context,
+such as in a ``for`` statement.
+
+This designates a subexpression that will be assigned a list of all
+items from the iterable being unpacked that are not assigned to any
+of the mandatory expressions, or an empty list if there are no such
+items.
+
+It is an error (as it is currently) if the iterable doesn't contain
+enough items to assign to all the mandatory expressions.
+
+
+Implementation
+==============
+
+The proposed implementation strategy is:
+
+- add a new grammar rule, ``star_test``, which consists of ``'*'
+  test`` and is used in test lists
+- add a new ASDL type ``Starred`` to represent a starred expression
+- catch all cases where starred expressions are not allowed in the AST
+  and symtable generation stage
+- add a new opcode, ``UNPACK_EX``, which will only be used if a
+  list/tuple to be assigned to contains a starred expression
+- change ``unpack_iterable()`` in ceval.c to handle the extended
+  unpacking case
+
+Note that the starred expression element introduced here is universal
+and could be used for other purposes in non-assignment context, such
+as the ``yield *iterable`` proposal.
+
+The author has written a draft implementation, but there are some open
+issues which will be resolved in case this PEP is looked upon
+benevolently.
+
+
+Open Issues
+===========
+
+- Should the catch-all expression be assigned a list or a tuple of items?
+
+
+References
+==========
+
+None yet.
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
+
+
+..
+   Local Variables:
+   mode: indented-text
+   indent-tabs-mode: nil
+   sentence-end-double-space: t
+   fill-column: 70
+   coding: utf-8
+   End: