[Python-3000] PEP3102 Keyword-Only Arguments

Guido van Rossum guido at python.org
Mon Aug 14 20:04:19 CEST 2006


On 8/14/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> On 8/14/06, Guido van Rossum <guido at python.org> wrote:
> > I believe the PEP doesn't address the opposite use case: positional
> > arguments that should *not* be specified as keyword arguments. For
> > example, I might want to write
> >
> >   def foo(a, b): ...
> >
> > but I don't want callers to be able to call it as foo(b=1, a=2) or
> > even foo(a=2, b=1).
>
> Another use case is when you want to accept the arguments of another
> callable, but you have your own positional arguments::
>
>     >>> class Wrapper(object):
>     ...     def __init__(self, func):
>     ...         self.func = func
>     ...     def __call__(self, *args, **kwargs):
>     ...         print 'calling wrapped function'
>     ...         return self.func(*args, **kwargs)
>     ...
>     >>> @Wrapper
>     ... def func(self, other):
>     ...     return self, other
>     ...
>     >>> func(other=1, self=2)
>     Traceback (most recent call last):
>       File "<interactive input>", line 1, in ?
>     TypeError: __call__() got multiple values for keyword argument 'self'
>
> It would be really nice in the example above to mark ``self`` in
> ``__call__`` as a positional only argument.

But this is a rather unusual use case isn't it? It's due to the bound
methods machinery. Do you have other use cases? I would assume that
normally such wrappers take their own control arguments in the form of
keyword-only arguments (that are unlikely to conflict with arguments
of the wrapped method).

> > Perhaps we can use ** without following identifier to signal this?
> > It's not entirely analogous to * without following identifier, but at
> > least somewhat similar.
>
> I'm certainly not opposed to going this way, but I don't think it
> would solve the problem above since you still need to take keyword
> arguments.

Can you elaborate?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-3000 mailing list