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

[Nick Coghlan]

On Sat, Mar 3, 2012 at 5:28 AM, Guido van Rossum <guido at python.org> wrote:
>> 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.

Yeah, on reflection, I'm actually -0 on adding keyword arg support to
1-arg functions.

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

I currently write such code as:

     def f(*args):
         arg1, arg2, arg3 = args

This gives rubbish error messages when the caller makes a mistake, but it works.

The obvious syntactic alternative is allowing tuple expansion
specifically for *args:

   def f(*(arg1, arg2, arg3)):
      pass

Then the interpreter would have enough info to still generate nice
error messages, and we don't have to invent much in the way of new
syntax.

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

Good point.

The other use case is APIs like the dict constructor and dict.update
which are designed to accept arbitrary keyword arguments, so you don't
want to reserve particular names in the calling argument namespace for
your positional arguments.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia