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

[Steven D'Aprano]

Guido van Rossum wrote:
> On Sat, Mar 3, 2012 at 4:55 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> On Sat, 3 Mar 2012 09:54:03 -0800
>> Guido van Rossum <guido at python.org> wrote:
>>>> 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.
>> Those situations are probably very rare. AFAIK we haven't seen anyone
>> mention a serious use case. I think concerns of built-in functions
>> shadowed by Python functions or the reverse are mostly academic, since
>> we don't see anyone complaining about dict-alikes accepting keyword
>> args.
> 
> No, because the base class's insistence on positional args makes it a
> non-starter to use keyword args.
> 
> But APIs that are implemented in Python don't have this nudge. Given
> that some folks here have expressed a desire to use keyword args
> *everywhere*, which I consider going way overboard, as a readability
> and consistency advocate I want to be able to remind them strongly in
> some cases not to do that.

I think you're reading too much into what has been a pretty luke-warm response 
to Gregory's suggestion.

As far as I can see, I've been the least negative about the idea, and that was 
a half-hearted +0. I described it as "nice to have" specifically on the basis 
of consistency, to minimize the differences between pure-Python functions and 
built-ins.

On reflection, your argument about subclassing built-ins has convinced me to 
drop that to a -1: if we were designing Python from scratch, it would be a 
nice-to-have for built-ins to take named arguments, but since they don't, it 
would be too disruptive to add them en-mass.

I'm still +1 on adding named arguments to built-ins where needed, e.g.

 >>> "spam".find('a', end=1)
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
TypeError: find() takes no keyword arguments

but I hope that would be uncontroversial!



>> (besides, what happened to "consenting adults"? :-))
> 
> We used to say that about the lone star feature too. But it's turned
> out quite useful, both for readability (require callers to name the
> options they're passing in) and for allowing evolution of a signature
> by leaving the option to add another positional argument in the
> future.
> 
> Some folks seem to believe that keywords are always better. I want to
> send a strong message that I disagree.

Positional-only arguments should be considered a new feature that requires 
justification, not just to send a message against mass re-engineering of 
built-ins.

Some arguments in favour:

* Consistency with built-ins.

* Functions that take a single argument don't need to be called by keyword.

(But is that a reason to prohibit it?)

* It gives the API developer another choice when designing their function API. 
Maybe some people just don't like keyword args.

(But is "I don't like them" a good reason to prohibit them? I'd feel more 
positive about this argument if I knew a good use-case for designing a new 
function with positional-only arguments.)


Arguments against:

* YAGNI. The subclass issue is hardly new, and as far as I know, has never 
been an actual problem in practice. Since people aren't calling subclass 
methods using keywords, why try to enforce it?

* It's another thing to learn about functions. "Does this function take 
keyword arguments or not?"


So far, I'm +0 on this.



>>> 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.
>> -1 on a built-in for that. The functools module would probably be a
>> good recipient (assuming the decorator is useful at all, of course).
> 
> TBH, I've never gotten the hang of functools. It seems mostly a refuge
> for things I don't like; so @positional() doesn't belong there. :-)

What, you don't like @wraps? Astonishing! :-)



-- 
Steven