Pythonification of the asterisk-based collection packing/unpacking syntax

[Steven D'Aprano]

On Sun, 25 Dec 2011 07:38:17 -0800, Eelco wrote:

> On Dec 25, 2:12 pm, Steven D'Aprano <steve
> +comp.lang.pyt... at pearwood.info> wrote:
>> On Sat, 24 Dec 2011 06:39:39 -0800, Eelco wrote:
>> > On Dec 20, 4:30 am, alex23 <wuwe... at gmail.com> wrote:
>> >> On Dec 19, 8:15 pm, Eelco <hoogendoorn.ee... at gmail.com> wrote:
>>
>> >> > What does that have to do with collection packing/unpacking?
>>
>> >> It's mocking your insistance that collection unpacking is a type
>> >> constraint.
>>
>> > This is really going to be the last time I waste any words on this:
>>
>> If only that were true, but after sending this post, you immediately
>> followed up with FIVE more posts on this subject in less than half an
>> hour.
> 
> Did I waste any more words on collection packing and type constraints?
> No, I did not. (though I am about to, and am willing to do so for every
> question that seems genuinely aimed at engaging me on the matter)
> 
> Did I intend to say that I was going to let a single troll shut down my
> entire topic? No, I did not.

Ah, well whatever you *intended* wasn't clear from your comment. At least 
not clear to *me*.


[...]
> Yes, indeed it would be abuse of language to call this a type
> constraint, since the fact that y is a list is indeed an outcome of
> whatever happens to pop out at the right hand side. One could redefine
> the identifier list to return any kind of object.

So far, we agree on this.

> How is 'head, *tail = sequence' or semantically entirely equivalently,
> 'head, tail::list = sequence' any different then? Of course after
> interpretation/compilation, what it boils down to is that we are
> constructing a list and binding it to the identifier tail, but that is
> not how it is formulated in python as a language 

I'm afraid it is.

Here's the definition of assignment in Python 3:
http://docs.python.org/py3k/reference/simple_stmts.html#assignment-
statements


> (all talk of types is
> meaningless after compilation; machine code is untyped).

What does machine code have to do with Python?


> We dont have
> something of the form 'tail = list_tail(sequence)'.

I'm afraid we do. See the definition of assignment again.


> Rather, we annotate
> the identifier 'tail' with an attribute that unquestionably destinates
> it to become a list*. It is no longer that 'tail' will just take
> anything that pops out of the expression on the right hand side; 

Of course it will. Python is a dynamically typed language. It doesn't 
suddenly develop static types to ensure that 'tail' becomes a list; 
'tail' is bound to a list because that's what the assignment statement 
provides.


> rather,
> the semantics of what will go on at right hand side is coerced by the
> constraint placed on 'tail'.

But it isn't a constraint placed on 'tail'. It is a consequence of the 
definition of assignment in Python 3. 'tail' becomes bound to a list 
because that is what the assignment statement is defined to do in that 
circumstance, not because the identifier (symbol) 'tail' is constrained 
to only accept lists. 'tail' may not even exist before hand, so talking 
about constraints on 'tail' is an abuse of language, AS YOU AGREED ABOVE.


[...]
> *(I call that a 'type constraint', because that is what it literally is;


No. It is literally a name binding of a dynamically typed, unconstrained 
name to an object which happens to be a list.


> if you can make a case that this term has acquired a different meaning
> in practice, and that there is another term in common use for this kind
> of construct; please enlighten me. Until that time, im going to ask you
> to take 'type constraint' by its literal meaning; a coercion of the type
> of a symbol,

But THERE IS NO COERCION OF THE TYPE OF THE SYMBOL.

I am sorry for shouting, but you seem oblivious to the simple fact that 
Python is not statically typed, and the symbol 'tail' is NOT coerced to a 
specific type. 'tail' may not even exist before the assignment is made; 
if it does exist, it could be *any type at all* -- and after the 
assignment takes place, there are no restrictions on subsequent 
assignments. 

'head, *tail = sequence' is no more a type constraint than 'x = 1' is.

Whatever the virtues of your proposal, you are doing it incalculable harm 
by your insistence on this incorrect model of Python's behaviour. 


-- 
Steven