[Python-ideas] keyword arguments everywhere (stdlib) - issue8706

[Guido van Rossum]

On Sun, Mar 4, 2012 at 8:57 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sun, 4 Mar 2012 13:46:33 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> Then the "_unpack_args" hack above would be unnecessary, and you could
>> just write:
>>
>>     class C:
>>
>>         def __init__(*(self, data=None), **kwds):
>>             self._stored_data = stored = {}
>>             if data:
>>                 stored.update(data)
>>             stored.update(kwds)
>>
>>         def update(*(self, data=None), **kwds):
>>             stored = self._stored_data
>>             if data is not None:
>>                 stored.update(data)
>>             stored.update(kwds)
>>
>> The objection was raised that this runs counter to the philosophy
>> behind PEP 3113 (which removed tuple unpacking from function
>> signatures). I disagree:
>> - this is not tuple unpacking, it is parameter binding
>> - it does not apply to arbitrary arguments, solely to the "extra
>> arguments" parameter, which is guaranteed to be a tuple
>> - it allows positional-only arguments to be clearly expressed in the
>> function signature, allowing the *interpreter* to deal with the
>> creation of nice error messages
>> - it *improves* introspection, since the binding of positional only
>> arguments is now expressed clearly in the function header (and
>> associated additional metadata on the function object), rather than
>> being hidden inside the function implementation
>
> Then please consider also re-introducing parameter tuple unpacking,
> since that was genuinely useful.

That's debatable - reread PEP 3113.

I added my +1 to Nick's proposal a little hastily, it should have been
+0. I think that *if* we want to solve this, my '/' solution should
also be on the table. It has the downside of not being obvious, but I
don't think that Nick's proposal is all that obvious either to people
who encounter it for the first time -- you have to combine a bunch of
powerful ideas to "get" it. And the () inside () just *begs* for
arbitrary nesting, which we don't want to reintroduce. We don't want
this:

def foo(*(*(*(a, b), c), d), e): ... :-)

-- 
--Guido van Rossum (python.org/~guido)