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

Ethan Furman ethan at stoneleaf.us
Sun Mar 4 16:34:49 CET 2012


David Townshend wrote:
> 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?

The problem with *args is that it allows 0-N arguments, when we want, 
say, 2.


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

Again, the problem is *args accepts a range of possible arguments.


> 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)

Not good.  The issue is not restricting the author from binding the 
positional arguments to names, the issue is restricting the user from 
binding the arguments to names -- but even then, the user (and the 
author!) need to have those names apparent.

For example:

   str.split(pos(2))

Quick, what should be supplied for the two positional arguments?

We want the arguments bound to names *in the function* -- we don't want 
the arguments bound to names *in the function call*.

~Ethan~



More information about the Python-ideas mailing list