[Python-3000] PEP 3132: Extended Iterable Unpacking

Wed May 2 00:55:55 CEST 2007

This reminds me a lot of haskell/prolog's head/tail list splitting. Looks
like a good feature.

a*=range(5)
hmmn maybe in such a case, whenever there is the * operator, the resulting
item is always a list/tuple, like the following:
 a=[[0,1,2,3,4]] ?

I have another question, what would happen in the case a*,b=tuple(range(5))

a = (0,1,2,3) ?

Should this keep the same type of container i.e. lists to lists and tuples
to tuples or always convert to list?

-Neville

On 5/2/07, Guido van Rossum <guido at python.org> wrote:
>
> 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/)
> _______________________________________________
> 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/nevillegrech%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20070502/7efb8918/attachment.html 