Pythonification of the asterisk-based collection packing/unpacking syntax

[Steven D'Aprano]

On Sun, 18 Dec 2011 06:13:37 -0800, Eelco wrote:

> Casts or conversions are a runtime concept; im talking about
> declarations. That seems to be the source of your confusion.

Everything in Python happens at runtime, apart from compilation of source 
code into byte code. Python doesn't have declarations. Even class and def 
are statements which happen at runtime, not declarations which happen at 
compile time.

Your proposal will be no different: if it happens, it will happen at 
runtime.


[...]
> I guess this use of the term entered my lexicon through the
> C# developer team. Either way, you seem to be the only one who does not
> grok my intended meaning, so I suggest you try reading it again.

I grok your *intended* meaning. I also grok that you are using the wrong 
words to explain your intended meaning.

"head, *tail = iterable" is not a declaration in Python. It is not a type 
conversion, or a constraint, or a cast. It is an iterator unpacking 
operation. It is syntactic sugar for something similar to this:

tmp = iter(iterable)
head = next(tmp)
tail = []
try:
    while True:
        tail.append(next(tmp))
except StopIteration:
    pass
del tmp


The only constraint is on the *input* to the operation: the right hand 
side object must obey the iterator protocol. The only conversion (if we 
want to call it such) is that an iterator object is created by the right 
hand side object.

[...]
> head, tail = l and head, *tail = l mean something completely different,

They are both iterator unpacking, and therefore by definition not 
"completely different". The first one is syntactic sugar for something 
like this:

tmp = iter(iterable)
head = next(tmp)
tail = next(tmp)
if tmp is not empty: raise exception
del tmp


and the second as shown earlier. Clearly they are quite similar: the only 
difference is that in the first case, the right hand side must have 
exactly two items, while in the second case, the right hand side can have 
an arbitrary number of items.


> and the only difference is a constraint placed on tail, which forces the
> semantics to be different; the righthand side, or what is to be
> assigned, is identical. Of course one can just regard it as syntactic
> sugar for head, tail = unpackheadandtailaslist(l); but the syntactic
> sugar achieves that same end through a type constraint on tail. Really.

All the words are in English, but I have no understanding of what you are 
trying to say here. What is unpackheadandtailaslist and how does it 
differ from actual unpacking in Python?


>> You are jumping to conclusions about implementation details which
>> aren't supported by the visible behaviour. What evidence do you have
>> that iterator unpacking creates a tuple first and then converts it to a
>> list?
> 
> You are jumping to conclusions about my opinion which aren't supported
> by my visible behaviour. What evidence do you have that I ever even said
> any such thing?

My evidence was your actual words, quoted in my post, which you deleted 
in your response.

Here they are again:

    [quote]
    This changes the semantics from normal unpacking, to unpacking 
    and then repacking all but the head into a list.
    [end quote]

In context, "this changes..." refers to extended iterator unpacking in 
the form "head, *tail" contrasted with "head, tail =...", and that it 
generates a list.

It may very well be that I have misunderstood you. If you do not intend 
the meaning that extended tuple unpacking first unpacks to a tuple and 
then re-packs to a list, then please explain what you did mean.


>> > The aim of this PEP, is that this type-constraint syntax is expanded
>> > upon. We should be careful here to distinguish with providing
>> > optional type constraints throughout python as a whole; this is not
>> > our aim.
>>
>> Iterator unpacking is no more about type constraints than is len().
> 
> Because you wish to keep nitpicking about my usage of the term 'type
> constraint' (even though you have not introduced an alternative term
> yourself), or because you actually disagree with the content of my
> message?

I don't think much about your proposal. I think it is unnecessary, based 
on a profound misunderstanding of how Python actually operates, badly 
explained using inappropriate terms, and the syntax you propose is ugly.


-- 
Steven