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
--
http://mail.python.org/mailman/listinfo/python-list
