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

[Bernhard Herzog]

me at mikerobin.com (Michael Robin) writes:

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

Well, you said (as quoted above) that you see no reason to disallow it
and then went on to give an example with parentheses instead of square
brackets. It looked to me as if you thought that I proposed that the
parenthesized version be disallowed too. Sorry if I misread that.

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

That's pretty much my view of sequence unpacking, yes,..

> therefore it makes sense to allow [] along with (),

... but I don't see the "therefore". All that matters is the
sequenceness of the RHS, not the actual types.

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

The list only exists on the RHS. On the LHS you only have the items of
the list and whether they're mutable has nothing to do with the fact
that they were pulled from a list.

Perhaps I'm misunderstanding you here, though.

> (And hey, let's give
> future type-inference systems, human or machine, as much information
> as they can get.)

Well, as long as the current semantics of sequence unpacking aren't
changed, it doesn't matter whether you use list or tuple syntax on the
LHS. The information a type-inference system can get from it is the same
in both cases.

Changing this so that it does make a difference whether you use () or []
would actually be a step back in Python's development, but you're not
advocating that, I think.


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

As I read it, the LHS only applied to the names, but not necessarily the
tuples/lists and since the mutability can only apply to the RHS anyway I
thought you were talking about the mutability of the sequence on the
right. There's not actual sequence object that you're assigning into on
the LHS, after all, and mutability is a property of objects.


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

I assume you mean something like seq[0] = value which would work if seq
is a list but not if it's a tuple because one is mutable but the other
isn't...

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

...and thus [] would make more sense because it looks like you're
modifying the contents of a list. I suppose that one can look at it that
way.

I think of something like 
        a, b = seq
more as a shortcut for (modulo slight differences):
        a = seq[0]
        b = seq[1]

basically, I think of the LHS as a sequence of assignment targets, but
not as sequence object (that's also more or less the way it's described
in the language reference).

How do others think about this?

> If unpacking works "for all kinds of sequences with length 2" (your
> words), why wouldn't the LHS follow suit?

If I don't care what kind of sequence it is, why shuld I try to
distinguish between two of them?


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

What would that mean?

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Sketch                                 http://sketch.sourceforge.net/
MapIt!                                               http://mapit.de/