[Python-3000] PEP 3132: Extended Iterable Unpacking (original) (raw)

Guido van Rossum guido at python.org
Wed May 2 00:00:33 CEST 2007

On 5/1/07, Georg Brandl <g.brandl at gmx.net> wrote:

This is a bit late, but it was in my queue by April 30, I swear! ;)

Accepted.

Comments are appreciated, especially some phrasing sounds very clumsy to me, but I couldn't find a better one.

Georg

PEP: 3132 Title: Extended Iterable Unpacking Version: RevisionRevisionRevision Last-Modified: DateDateDate 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]

Has it been pointed out to you already that this particular example is hard to implement if the RHS is an iterator whose length is not known a priori? The implementation would have to be quite hairy -- it would have to assign everything to the list b until the iterator is exhausted, and then pop a value from the end of the list and assign it to c. it would be much easier if *b was only allowed at the end. (It would be even worse if b were assigned a tuple instead of a list, as per your open issues.)

Also, what should this do? Perhaps the grammar could disallow it?

*a = range(5)

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, startest, 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, UNPACKEX, which will only be used if a list/tuple to be assigned to contains a starred expression - change unpackiterable() 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. -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

Python-3000 mailing list Python-3000 at python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list