[Python-ideas] keyword arguments everywhere (stdlib) - issue8706
steve at pearwood.info
Sun Mar 4 04:42:30 CET 2012
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
>>> 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
> 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
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
> 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
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.)
* 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! :-)
More information about the Python-ideas