[Python-Dev] Extending tuple unpacking

Nick Coghlan ncoghlan at gmail.com
Wed Oct 12 11:41:56 CEST 2005


Steve Holden wrote:
> But don't forget that at present unpacking can be used at several levels:
> 
>  >>> ((a, b), c) = ((1, 2), 3)
>  >>> a, b, c
> (1, 2, 3)
>  >>>
> 
> So presumably you'd need to be able to say
> 
>    ((a, *b), c, *d) = ((1, 2, 3), 4, 5, 6)
> 
> and see
> 
>    a, b, c, d == 1, (2, 3), 4, (5, 6)
> 
> if we are to retain today's multi-level consistency.

That seems reasonable enough. I'd considered such code bad style though.

And are you also
> proposing to allow
> 
>    a, *b = [1]
> 
> to put the empty list into b, or is that an unpacking error?

It does the same as function parameter unpacking does, by making b the empty 
tuple.

> This would allow users to provide an arbitrary number of positionals 
> rather than having them become keyword arguments. At present it's 
> difficult to specify that.

That's the reasoning behind the "* without a name" idea:

    def f(a, b, c=default, *, foo=1, bar=2): pass

Here, c is a positional argument with a default value, while foo and bar are 
forced to be keyword arguments.

Completely nuts idea #576 wold involve extending this concept past the keyword 
dict as well to get function default values which aren't arguments:

    def f(pos1, pos2, pos3=default, *,
          kw1=1, kw2=2, **,
          const="Nutty idea"):
        pass

Py> f(const=1)
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
TypeError: f() got an unexpected keyword argument 'const'

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com


More information about the Python-Dev mailing list