[Python-3000] PEP 3132: Extended Iterable Unpacking

[Guido van Rossum]

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: $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]

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, ``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.
>
>
> --
> 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/)