[Python-Dev] syntactic shortcut - unpack to variably sized list

[Carlos Ribeiro]

On Fri, 19 Nov 2004 20:29:45 +1000, Nick Coghlan <ncoghlan at iinet.net.au> wrote:
> Carlos Ribeiro wrote:
> > list.pop doesn't solve the case for  when the data is stored in a
> > tuple (which is immutable).
> 
> For immutable objects, you *have* to make a copy, so I don't see any real
> downside to just using:
> 
>    a, b, T = T[0],  T[1], T[2:]

(First of all, let me say that I am not at all against making list.pop
accept slices. It's nice that it seems to be agreed that this is a
worthy addition. And I don't intend to keep pushing for iunpack(); but
I feel that is important to make a few clarifications.)

If I want to do:

a,b,X = T[0],  T[1], T[2:]   (?)

The lesson here is that it can't be assumed for unpacking purposes
that the programmer wanted to modify the original list. Of course, if
he does want it, then list.pop just comes nice.

(also, list.pop(slice) can be used to remove elements from anywhere on
the list, which is a big plus)

> While I think iunpack is kind of neat, I don't think it solves anything which is
> currently a major problem, as it is really just a different way of spelling the
> above slicing. The major portion (sans some index checking) of iunpack(T, 2) can
> be written on one line:
> 
>    a, b, T = (T[i] for i in (range(2) + [slice(2, None)]))

I would rather prefer not to have to use this idiom -- it's neither
obvious nor convenient. Either list.pop or unpack would be cleaner for
this purpose.

> When the number of elements to be unpacked is known at compile time (as it has
> to be to use tuple unpacking assignment), there seems little benefit in moving
> things inside a generator instead of spelling them out as a tuple of slices.

For more than a few arguments, it seems to be silly to require the
user to write it as:

a,b,c,d,e = t[0],t[1],t[2],t[3],t[4:]

[lots of remarks about list.pop snipped]

I'm not against list.pop; it's just that iunpack provides a different
approach to the problem. It's fairly generic: it works for both
mutable and immutable lists. The implementation provided is a proof of
concept. The fact that it does not modify the original arguments *is*
a design feature (althought not what the OP wanted for his particular
case). After all, as shown in the example above, conventional tuple
unpacking on assignment doesn't change the right-side arguments
either.

One posible improvement for iunpack() is to accept any iterable as an
argument. On return, instead of a tuple to represent the remaining
elements, it would return the generator itself. This would allow for
code that consume the generator in "chunks" to be written rather
simply:

a,b,c,g = iunpack(3, g)

In this case, to solve the OP problem, instead to have all the values
to be processed stored into a list, he could rely on a generator to
produce values on the fly. Depending on the scenario this would come
handy (less memory consumption, more responsiveness).

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro at gmail.com
mail: carribeiro at yahoo.com