[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