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

[Ron Adam]

On Sat, 2012-03-03 at 09:54 -0800, Guido van Rossum wrote:
> On Sat, Mar 3, 2012 at 7:20 AM, Ron Adam <ron3200 at gmail.com> wrote:
> > It seems to me that sometimes the writer of functions wish to have more
> > control of how the function is called, but I think it is better that the
> > user of a function can select the calling form that perhaps matches the
> > data and/or style they are using more closely.
> 
> Um, the function author chooses the signature. If you disagree with
> that signature, tough luck.

Yes, except the caller does have the option to use the *args and/or
**kwds and other variations of packing and unpacking when it's
convenient.  And yes, I realize it doesn't really change the signature
it self, but it is a different way to spell a function call and
sometimes is very helpful when the data can be matched to the signature.

For example, by not specifying any arguments as keyword only, or
position only, both of the following examples work, and the function
caller has these options.

>>> def foo(a, b):
...    return a, b
... 
>>> kwds = dict(a=1, b=2)
>>> foo(**kwds)
(1, 2)
>>> args = (1, 2)
>>> foo(*args)
(1, 2)

But by specify an argument as keyword only, then it removes the *args
option.

And also if an argument is specified as position only, then the **kwds
spelling wont work.

I'm not suggesting there isn't sometimes a need for being more specific,
but that quite often it's nicer to let the caller have those options
rather than limit the API too narrowly.


> > I hope in the future that we find ways to simplify function signatures
> > in a way that make them both easier to use and more efficient for the
> > function user, rather than continue adding specific little tweaks that
> > give the function designer more control over how the function user calls
> > it.
> 
> You seem to forget that API design is an art and that it is the
> function author's prerogative to design an API that minimizes mistakes
> for all users of the function. Sometimes that includes requiring that
> everyone uses positional arguments for a certain situation.

I was trying to make a more general point which is why I preceded my
comments with, "On a more general note...", which was left out of the
reply.

Yes, it most definitely is an ART to create a good API.  And also yes,
sometimes minimizing errors take priority, especially when those errors
can be very costly.

It seems to me, binding an object by name is less likely to be wrong
than binding a object by it's position.

The advantage of 'by position' is that many objects are stored in
ordered lists.  ie.. [start, stop, step], [x, y, z].  So it's both
easier and more efficient to use the position rather than a name
especially if the object can be *unpacked directly into the signature.

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>

Cheers,
   Ron


> Anyway, I now think that adding a built-in @positional(N) decorator
> makes the most sense since it doesn't require changes to the parser.
> The built-in can be implemented efficiently. This should be an easy
> patch for someone who wants to contribute some C code.