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

David Townshend aquavitae69 at gmail.com
Sun Mar 4 17:24:27 CET 2012

On Sun, Mar 4, 2012 at 5:34 PM, Ethan Furman <ethan at stoneleaf.us> wrote:

> 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.
Agreed, but why not this?

def f(*args, **kwargs):
    assert len(args) == 2

The exception raised could easily be a TypeError too, so it would appear,
to a user, the same as defining it in the function signature.  There are of
course, other limitations (e.g. introspection), but without a specific use
case it is difficult to know how important those limitations are.

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

Why does the user need the names?  If the user cannot use them as keywords,
then it doesn't matter what the names are, so anything can be used in the
documentation (which is the only place they would appear).  The author
doesn't need the names either, just the data they refer to, in this case a

> For example:
>  str.split(pos(2))
> Quick, what should be supplied for the two positional arguments?

Is that a function call or definition?  My suggestion was to use the
parenthesis in the definition, not the call.  Since str.split only has
optional arguments its not a good example, but if you were to redefine
str.replace (in python) it would look like this:

def replace(pos(3), count=None):
    self, old, new = pos

It would still be called in the same way though:

>>> 'some string'.replace('s', 't', 1)
'tome string'

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

That is what I proposed, I just suggested binding all of the
positinoal-only arguments to a single name.

Having given it a bit more thought, though, maybe it would be easier to
optionally apply the parenthesis to *args:

def replace(self, *args(2), count=None);
   old, new = args

This looks much closer to current situation, and I suppose could be
extended to **kwargs, limiting the number of keyword arguments (although I
have no idea why this would ever be wanted!)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20120304/057ecea0/attachment.html>

More information about the Python-ideas mailing list