Pythonification of the asterisk-based collection packing/unpacking syntax

[Eelco]

On Dec 25, 6:05 pm, Steven D'Aprano <steve
+comp.lang.pyt... at pearwood.info> wrote:
> 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*.

Always glad to help.

> > 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.

Good.

> > 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

Que?

'head, *tail = sequence'

Is how one currently unpacks a head and tail in idiomatic python

This is semantically equivalent to

'head = sequence[0]'
'tail = list(sequence[1:])'

But these forms are linguistically different, in too many different
ways to mention.

> > We dont have
> > something of the form 'tail = list_tail(sequence)'.
>
> I'm afraid we do. See the definition of assignment again.

Que?

My claim is that the two semantically identical formulations above do
not have isomorphic linguistic form. As far as I can make sense of
your words, you seem to be disputing this claim, but its a claim as
much worth debating as that the sun rises in the east.

> > 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.

How python accomplishes any of this under the hood is entirely
immaterial. The form is that of a compile-time type constraint,
regardless of whether the BDFL ever thought about it in these terms.

> > 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.

'tail' is (re)declared on the spot as a brand-new identifier (type
constraint included); whether it exists before has no significance
whatsoever, since python allows rebinding of identifiers.

> > *(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.

Let me take a step back and reflect on the form of the argument we are
having. I claim the object in front of us is a 'cube'. You deny this
claim, by countering that it is 'just a particular configuration of
atoms'.

'look at the definition!', you say; 'its just a list of coordinates,
no mention of cubes whatsoever.'.

'Look at the definition of a cube', I counter. 'This particular list
of coordinates happens to fit the definition, whether the BDFT
intended to or not'.

You are correct, in the sense that I do not disagree that it is a
particular configuration of atoms. But if you had a better
understanding of cubes, youd realize it meets the definition; the fact
that people might not make a habit of pausing at this fact (there is
generally speaking not much of a point in doing so in this case), does
not diminish the validity of this perspective. But again, if this
perspective does not offer you anything useful, feel free not to share
in it.

> > 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.

Whatever the virtues of your critique of my proposal, you might end up
wasting less time doing so by reading a book or two on compiler theory.