This reminds me a lot of haskell/prolog&#39;s head/tail list splitting. Looks like a good feature.<br><br>a*=range(5)<br>hmmn maybe in such a case, whenever there is the * operator, the resulting item is always a list/tuple, like the following:
<br>&nbsp;a=[[0,1,2,3,4]] ? <br><br>I have another question, what would happen in the case a*,b=tuple(range(5))<br><br>a = (0,1,2,3) ?<br><br>Should this keep the same type of container i.e. lists to lists and tuples to tuples or always convert to list?
<br><br>-Neville<br><br><div><span class="gmail_quote">On 5/2/07, <b class="gmail_sendername">Guido van Rossum</b> &lt;<a href="mailto:guido@python.org">guido@python.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 5/1/07, Georg Brandl &lt;<a href="mailto:g.brandl@gmx.net">g.brandl@gmx.net</a>&gt; wrote:<br>&gt; This is a bit late, but it was in my queue by April 30, I swear! ;)<br><br>Accepted.<br><br>&gt; Comments are appreciated, especially some phrasing sounds very clumsy
<br>&gt; to me, but I couldn&#39;t find a better one.<br>&gt;<br>&gt; Georg<br>&gt;<br>&gt;<br>&gt; PEP: 3132<br>&gt; Title: Extended Iterable Unpacking<br>&gt; Version: $Revision$<br>&gt; Last-Modified: $Date$<br>&gt; Author: Georg Brandl &lt;
<a href="mailto:georg@python.org">georg@python.org</a>&gt;<br>&gt; Status: Draft<br>&gt; Type: Standards Track<br>&gt; Content-Type: text/x-rst<br>&gt; Created: 30-Apr-2007<br>&gt; Python-Version: 3.0<br>&gt; Post-History:
<br>&gt;<br>&gt;<br>&gt; Abstract<br>&gt; ========<br>&gt;<br>&gt; This PEP proposes a change to iterable unpacking syntax, allowing to<br>&gt; specify a &quot;catch-all&quot; name which will be assigned a list of all items
<br>&gt; not assigned to a &quot;regular&quot; name.<br>&gt;<br>&gt; An example says more than a thousand words::<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; &gt;&gt;&gt; a, *b, c = range(5)<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; &gt;&gt;&gt; a<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; 0<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; &gt;&gt;&gt; c
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; 4<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; &gt;&gt;&gt; b<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; [1, 2, 3]<br><br>Has it been pointed out to you already that this particular example is<br>hard to implement if the RHS is an iterator whose length is not known<br>a priori? The implementation would have to be quite hairy -- it would
<br>have to assign everything to the list b until the iterator is<br>exhausted, and then pop a value from the end of the list and assign it<br>to c. it would be much easier if *b was only allowed at the end. (It<br>would be even worse if b were assigned a tuple instead of a list, as
<br>per your open issues.)<br><br>Also, what should this do? Perhaps the grammar could disallow it?<br><br>*a = range(5)<br><br>&gt; Rationale<br>&gt; =========<br>&gt;<br>&gt; Many algorithms require splitting a sequence in a &quot;first, rest&quot; pair.
<br>&gt; With the new syntax, ::<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; first, rest = seq[0], seq[1:]<br>&gt;<br>&gt; is replaced by the cleaner and probably more efficient::<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; first, *rest = seq<br>&gt;<br>&gt; For more complex unpacking patterns, the new syntax looks even
<br>&gt; cleaner, and the clumsy index handling is not necessary anymore.<br>&gt;<br>&gt;<br>&gt; Specification<br>&gt; =============<br>&gt;<br>&gt; A tuple (or list) on the left side of a simple assignment (unpacking<br>
&gt; is not defined for augmented assignment) may contain at most one<br>&gt; expression prepended with a single asterisk.&nbsp;&nbsp;For the rest of this<br>&gt; section, the other expressions in the list are called &quot;mandatory&quot;.
<br>&gt;<br>&gt; Note that this also refers to tuples in implicit assignment context,<br>&gt; such as in a ``for`` statement.<br>&gt;<br>&gt; This designates a subexpression that will be assigned a list of all<br>&gt; items from the iterable being unpacked that are not assigned to any
<br>&gt; of the mandatory expressions, or an empty list if there are no such<br>&gt; items.<br>&gt;<br>&gt; It is an error (as it is currently) if the iterable doesn&#39;t contain<br>&gt; enough items to assign to all the mandatory expressions.
<br>&gt;<br>&gt;<br>&gt; Implementation<br>&gt; ==============<br>&gt;<br>&gt; The proposed implementation strategy is:<br>&gt;<br>&gt; - add a new grammar rule, ``star_test``, which consists of ``&#39;*&#39;<br>&gt;&nbsp;&nbsp; test`` and is used in test lists
<br>&gt; - add a new ASDL type ``Starred`` to represent a starred expression<br>&gt; - catch all cases where starred expressions are not allowed in the AST<br>&gt;&nbsp;&nbsp; and symtable generation stage<br>&gt; - add a new opcode, ``UNPACK_EX``, which will only be used if a
<br>&gt;&nbsp;&nbsp; list/tuple to be assigned to contains a starred expression<br>&gt; - change ``unpack_iterable()`` in ceval.c to handle the extended<br>&gt;&nbsp;&nbsp; unpacking case<br>&gt;<br>&gt; Note that the starred expression element introduced here is universal
<br>&gt; and could be used for other purposes in non-assignment context, such<br>&gt; as the ``yield *iterable`` proposal.<br>&gt;<br>&gt; The author has written a draft implementation, but there are some open<br>&gt; issues which will be resolved in case this PEP is looked upon
<br>&gt; benevolently.<br>&gt;<br>&gt;<br>&gt; Open Issues<br>&gt; ===========<br>&gt;<br>&gt; - Should the catch-all expression be assigned a list or a tuple of items?<br>&gt;<br>&gt;<br>&gt; References<br>&gt; ==========
<br>&gt;<br>&gt; None yet.<br>&gt;<br>&gt;<br>&gt; Copyright<br>&gt; =========<br>&gt;<br>&gt; This document has been placed in the public domain.<br>&gt;<br>&gt;<br>&gt; --<br>&gt; Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
<br>&gt; Four shall be the number of spaces thou shalt indent, and the number of thy<br>&gt; indenting shall be four. Eight shalt thou not indent, nor either indent thou<br>&gt; two, excepting that thou then proceed to four. Tabs are right out.
<br>&gt;<br>&gt; _______________________________________________<br>&gt; Python-3000 mailing list<br>&gt; <a href="mailto:Python-3000@python.org">Python-3000@python.org</a><br>&gt; <a href="http://mail.python.org/mailman/listinfo/python-3000">
http://mail.python.org/mailman/listinfo/python-3000</a><br>&gt; Unsubscribe: <a href="http://mail.python.org/mailman/options/python-3000/guido%40python.org">http://mail.python.org/mailman/options/python-3000/guido%40python.org
</a><br>&gt;<br><br><br>--<br>--Guido van Rossum (home page: <a href="http://www.python.org/~guido/">http://www.python.org/~guido/</a>)<br>_______________________________________________<br>Python-3000 mailing list<br><a href="mailto:Python-3000@python.org">
Python-3000@python.org</a><br><a href="http://mail.python.org/mailman/listinfo/python-3000">http://mail.python.org/mailman/listinfo/python-3000</a><br>Unsubscribe: <a href="http://mail.python.org/mailman/options/python-3000/nevillegrech%40gmail.com">
http://mail.python.org/mailman/options/python-3000/nevillegrech%40gmail.com</a><br></blockquote></div><br>