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

Neville Grech Neville Grech nevillegrech at gmail.com
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: 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/)

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

More information about the Python-3000 mailing list