On Sat, Mar 3, 2012 at 5:28 AM, Guido van Rossum <guido@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@gmail.com | Brisbane, Australia