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

[Ron Adam]

On Sat, 2012-03-03 at 16:46 -0800, Guido van Rossum wrote:
> On Sat, Mar 3, 2012 at 4:15 PM, Ron Adam <ron3200 at gmail.com> wrote:
> > I just can't think of a good case where I would want to prohibit setting
> > an argument by name on on purpose.  But I suppose if I encountered a
> > certain error that may have been caught by doing so, I may think about
> > doing that. <shrug>
> 
> Apparently you skipped part of the thread. <shrug**2>

Yep, I missed Nicks message where he points out...

> The other use case is APIs like the dict constructor and dict.update
> which are designed to accept arbitrary keyword arguments, so you don't
> want to reserve particular names in the calling argument namespace for
> your positional arguments.


>>> def dct(a, **kwds):
...   return a, kwds

>>> dct(42, a=2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: dct() got multiple values for keyword argument 'a'

Would the positional decorator fix this particular case?  It seems like
it would work for forcing an error, but not for multiple values with the
same name.


The way to currently get around this is to use *args along with **kwds.

>>> def dct(*args, **kwds):
...     (n,) = args           # errors here if incorrect number of args.
...     return n, kwds
...
>>> dct(3, n=7, args=42, kwds='ok')
(3, {'args': 42, 'kwds': 'ok', 'n': 7})

The names used with '*' and '**' are already anonymous as far as the foo
signature is concerned, so you can use args or kwds as keywords without
a problem.

I'm not sure what the positional decorator would gains over this.


The other use case mentioned is the one where you point out overriding
an undocumented variable name.  Seems like this is a question of weather
or not it is better to make python behavior match the C builtins
behavior, vs making the C builtins behavior match python behavior.


Cheers,
   Ron