[Python-Dev] Extending tuple unpacking

Reinhold Birkenfeld reinhold-birkenfeld-nospam at wolke7.net
Tue Oct 11 20:43:59 CEST 2005

Greg Ewing wrote:
> Guido van Rossum wrote:
>> BTW, what should
>>     [a, b, *rest] = (1, 2, 3, 4, 5)
>> do? Should it set rest to (3, 4, 5) or to [3, 4, 5]?
> Whatever type is chosen, it should be the same type, always.
> The rhs could be any iterable, not just a tuple or a list.
> Making a special case of preserving one or two types doesn't
> seem worth it to me.

I don't think that

[a, b, c] = iterable

is good style right now, so I'd say that

[a, b, *rest] = iterable

should be disallowed or be the same as with parentheses. It's not
intuitive that rest could be a list here.

>> ? And then perhaps
>>     *rest = x
>> should mean
>>     rest = tuple(x)
>> Or should that be disallowed
> Why bother? What harm would result from the ability to write that?
>> There certainly is a need for doing the same from the end:
>>     *rest, a, b = (1, 2, 3, 4, 5)
> I wouldn't mind at all if *rest were only allowed at the end.
> There's a pragmatic reason for that if nothing else: the rhs
> can be any iterable, and there's no easy way of getting "all
> but the last n" items from a general iterable.
>> Where does it stop?
> For me, it stops with *rest only allowed at the end, and
> always yielding a predictable type (which could be either tuple
> or list, I don't care).

+1. Tuple is more consistent.

>> BTW, and quite unrelated, I've always felt uncomfortable that you have to write
>>     f(a, b, foo=1, bar=2, *args, **kwds)
>> I've always wanted to write that as
>>     f(a, b, *args, foo=1, bar=2, **kwds)
> Yes, I'd like that too, with the additional meaning that
> foo and bar can only be specified by keyword, not by
> position.

That would be a logical consequence. But one should also be able to give default values
for positional parameters. So:

foo(a, b, c=1, *args, d=2, e=5, **kwargs)
    ^^^^^^^^^         ^^^^^^^^
    positional        only with kw
    or with kw


Mail address is perfectly valid!

More information about the Python-Dev mailing list