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

[Guido van Rossum]

On Fri, Mar 2, 2012 at 4:13 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Fri, Mar 2, 2012 at 6:43 PM, Steven D'Aprano <steve at pearwood.info> wrote:
>> +1 on adding keyword arguments to built-in methods and functions where they
>> would help readability, e.g str.find(c, start=23), even if this happens in a
>> ad-hoc fashion.
>
> Indeed, this is the approach we have taken to date. For example,
> str.split() recently gained keyword support for 3.3 because
> "text.split(maxsplit=1)" is less cryptic than "text.split(None, 1)".
>
> It makes the most sense when at least one of the following holds:
> - the second argument accepts a number that is unclear if you're not
> familiar with the full function signature
> - the earlier arguments have sensible default values that you'd prefer
> not to override
>
> So +1 on declaring "make X support keyword arguments"
> non-controversial for multi-argument functions, +0 on also doing so
> for single argument functions, but -0 on attempting to boil the ocean
> and fix them wholesale.

Hm. I think for many (most?) 1-arg and selected 2-arg functions (and
rarely 3+-arg functions) this would reduce readability, as the example
of ord(char=x) showed.

I would actually like to see a syntactic feature to state that an
argument *cannot* be given as a keyword argument (just as we already
added syntax to state that it *must* be a keyword).

One area where I think adding keyword args is outright wrong: Methods
of built-in types or ABCs and that are overridable. E.g. consider the
pop() method on dict. Since the argument name is currently
undocumented, if someone subclasses dict and overrides this method, or
if they create another mutable mapping class that tries to emulate
dict using duck typing, it doesn't matter what the argument name is --
all the callers (expecting a dict, a dict subclass, or a dict-like
duck) will be using positional arguments in the call. But if we were
to document the argument names for pop(), and users started to use
these, then most dict sublcasses and ducks would suddenly be broken
(except if by luck they happened to pick the same name).

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