[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