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

[Guido van Rossum]

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.

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

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

-- 
--Guido van Rossum (python.org/~guido)