Pythonification of the asterisk-based collection packing/unpacking syntax

[Eelco]

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.

> > In case of python, collection PACKING (not unpacking) is signaled by a
> > construct that can be viewed as a type constraint.
>
> Only by doing sufficient violence to the concept of type constraint that
> it could mean *anything*.
>
> Earlier, I insisted that a constraint is a rule that applies to input,
> not output. I haven't seen anyone, including yourself, dispute that.
>
> Normally we would say that in the statement:
>
>     y = list(x)
>
> there is a constraint on x, namely that it is some sort of iterable
> object (otherwise an exception will be raised), but it would be an abuse
> of language to say that there is a type constraint on y. y ends up being
> a list, true, but that isn't a constraint on y, it is an outcome.
>
> In normal usage, "constraint" refers to pre-conditions, not post-
> conditions. There are no pre-conditions on y in the above. It may not
> even exist. Contrast it with this example:
>
>     y += list(x)
>
> where there are constraints on y: it must exist, and it must be a list,
> or something which can be added to a list.

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.

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 (all talk of types is
meaningless after compilation; machine code is untyped). We dont have
something of the form 'tail = list_tail(sequence)'. 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;
rather, the semantics of what will go on at right hand side is coerced
by the constraint placed on 'tail'.

But again, if you dont wish to view this as a type constraint, I wont
lose any sleep over that. In that case this line of argument was
simply never directed at you. It was directed at people who would
reasonably argue that 'tail::tuple is a type constraint and thats
unpythonic / type constraints have been considered and rejected'. If
you dont think it looks like a type constraint: fine. The simpler
argument is that whatever it is, its just a more verbose and flexible
variant of a construct that python already has.

*(I call that a 'type constraint', because that is what it literally
is; 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, rather than whatever particular
meaning it has acquired for you (it might help if you explained that).
Im not sure if it was you that brought that up, but let me reiterate
that I dont mean a 'type cast', which is a runtime concept. A 'type
constraint' is purely a linguistic construct that will be 'compiled
out')