Pythonification of the asterisk-based collection packing/unpacking syntax

[Eelco]

On 18 dec, 18:03, Steven D'Aprano <steve
+comp.lang.pyt... at pearwood.info> wrote:
> 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.


Of course it will have runtime effects; and compile/interpret-time
effects too. You said as much yourself: 'Everything in Python happens
at runtime, apart from compilation of source'.

Python *does* have declarations. Even though they may not be called
such in the documentation (dunno, havnt checked) the current use of *
and ** when not signifying collectiong UNpacking, is an annotation to
the declaration of the symbol that comes after it. In this case, a
constraint-on / specification-of the type of the object that the
variable symbol may bind; a list or tuple, depending on the context.

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

At least something we agree upon; all im proposing is an alternative
syntax for something thats already there. Lets be pragmatic and agree
to disagree on what it is that is already there, or what it ought to
be called. Because frankly, this has detracted enough already from
what it is I do want to discuss.

> [snipped staements of the obvious]
>
> 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.

Oh great, you found another semantic hair to split. Yes, they are
quite similar. Nonetheless, any python implementation that would
confuse the two behaviors would be considered badly bugged.


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

I have the impression you are not even trying then. Google 'syntactic
sugar'. It means 'semantically identical way of putting things', in
short. That tells you everything you need to know about
unpackheadandtailaslist: nothing.

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

Again, where did I say it first unpacks to a tuple? As far as im aware
that only happens in the context of a function call.

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

Which is not an aswer to the question I posed; just an expression of
frustration.

Its mutual.