Unpacking extension (Re: A small inconsistency in syntax?)

[Michael Robin]

Bernhard Herzog <bh at intevation.de> wrote in message news:<6qhesfsi72.fsf at abnoba.intevation.de>...
> me at mikerobin.com (Michael Robin) writes:
> 
> > I'd think there's no reason to disallow it. 
> > Although in Python the comma operator creates tuples 
> > rather than the parens, for many it looks as if
> >    a,b = seq 
> > is just shorthand for 
> >    (a,b) = seq
> 
> This version would not be removed. You need some kind of grouping to
> support nested unpackings.

I don't think I ever suggested it would be removed.
I was pointing out the asymetry in the list vs. tuple literal
building syntax (containment/nesting vs. seperator, respectivily),
and how although semantically similar, []'s are required
in lists, but ()'s are not required for tuples. 
(I'm not saying this is good or bad, mind you.) If you 
like being explict with (a,b), Python should allow [a,b].
If there were a "generic" sequence literal, this would be 
the place for one, but there is not.

> Why, if it doesn't make a difference at all?
> a, b = t
> (a, b) = t
> [a, b] = t
> are completely equivalent. They all generate the same bytecode and work
> for all kinds of sequences with length 2.

As per my previous post, one could view "tuple unpacking" as either
(a) A degenerate (though very useful) form of unification or, (b) a
seperate language feature totally unto itself, resembling
multiple-value binding -- although it is less general than unification
and more general than retrieving multiple values from a fn. (Although
it is commonly used for the latter.)
If your view is (b) then "a, b = foo" would be the preferred and only
syntax, but because *the shape of the LHS matters* (as in "a, [b, (c,
d)] = foo") some form of nesting is reqired in the LHS; therefore it
makes sense to allow [] along with (), especially since it is more
self-documenting if, in fact, you are unpacking a list rather than a
tuple in a particular portion of the structure to be unpacked (meaning
that you can modify it after unpacking it, etc). (And hey, let's give
future type-inference systems, human or machine, as much information
as they can get.)
 
> > Also, given that lists are mutable and tuples are
> > not, the list notation makes some kind of sense,
> > even though you're rebinding the names in the LHS
> > rather than creating a list, per se.
> 
> In my eyes the mutability of the RHS doesn't enter into it. All that
> matters is that it's a sequence of the right length.

I belive I said LHS, not RHS, as we were on the topic 
of the syntax of the name list - but in any case
I agree - I never said it mattered. The point was 
that orinarilly "aList = RHS" is allowed, but 
"aTuple = RHS" is not; therefore []'s "make some
kind of sense", given that the syntax for unpacking
is identical to assiging to a literal sequence, and
that, in fact, you are causing a side-effect.

If unpacking works "for all kinds of sequences with length 2" (your
words), why wouldn't the LHS follow suit? (At least for literals - I'm
not suggesting you should be able to do:
    someObjectThatImplements_setitem_() =
       somethingThatImplements_getitem_or_iter()
 - but wait... :) (No, seriously - way to dangerous...))

> 
>    Bernhard

mike