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

[David Townshend]

On Sun, Mar 4, 2012 at 6:16 AM, Ron Adam <ron3200 at gmail.com> wrote:

> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>

There are two issues being discussed here:

1.  A new syntax for positional-only arguments.  I don't really see any
good use case for this which can't already be dealt with quite easily using
*args.  True, it means a bit more work on the documentation, but is it
really worth adding new syntax (or even a built-in decorator) just for that?

2.  How to avoid the problems with name-binding to an intended positional
only argument.  Once again, this can be dealt with using *args.

In both cases it would be nice to be able to avoid having to manually parse
*args and **kwargs, but I haven't really seen anything better that the
status quo for dealing with them. The only way I see this really working is
to somehow bind positional-only arguments without binding each them to a
specific name, and the only way I can think of to do that is to store them
in a tuple.  Perhaps, then, the syntax should reflect a C-style array:

# pos(2) indicates 2 positional arguments
def f(pos(2), arg1, *args, **kwargs):
    print(pos)
    print(arg1)
    print(args)
    print(kwargs)

>>> f(1, 2, 'other', 'args', pos='arguments')
(1, 2)
'other'
('args',)
{'pos': 'arguments'}

I'm +0 on the whole idea, but only if it deals with both issues.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20120304/7512b0eb/attachment.html>