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

[Michael Robin]

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
and if it unpacks lists too (which it does)
you may as well have the option of being
explicit in your LHS pattern.
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.

I think one issue is that tuple unpacking looks an
awful lot like unification pattern matching
a la prolog, because the shape of the LHS
effects unpacking, in which case you'd expect a lot.
But it's only ShapeAssign(LHS<--RHS) rather than
Unify( LHS<-->RHS).
Unpacking is a little to the left between
multiple assignment and unification, which
makes it pretty unique (i think?).
I certainly can live w/o "[a,b] = foo" -
but just another viewpoint...

-------------
Bernhard Herzog <bh at intevation.de> wrote in message news:<6q1yjkvpi6.fsf at abnoba.intevation.de>...
> "Steve Holden" <sholden at holdenweb.com> writes:
> 
> > <James_Althoff at i2.com> wrote in ...
> > >
> > > Bernhard Herzog wrote:
> > > >Personally, I wouldn't mind to see the "[a,b] = sequence" syntax go.
> > >
> > > I agree.  I think it's confusing and adds no value (unless I'm missing
> > > something).
> > >
> > But since it's been permissible for a long time, removing it might break
> > existing code. Would you propose a PEP to go through the "from __future__
> > ..." phase and arrive at "feature removed"? As far as I'm concerned it
> > remains a quirk, which I could easily live without but equally easily
> > ignore.
> 
> Certainly, and since it's relatively unimportant, it would be probably
> best to remove it in 3.0, since that will at least some other
> incompatible change like the behavior of the division operator.
> 
>    Bernhard