Please explain why these two built-in functions behave differently when passed in keyword arguments

Question

Consider these different behaviors:

>> def minus(a, b): >> return a - b >> minus(**dict(b=2, a=1)) -1 >> int(**dict(base=2, x='100')) 4 >> import operator >> operator.sub.__doc__ 'sub(a, b) -- Same as a - b.' >> operator.sub(**dict(b=2, a=1)) TypeError: sub() takes no keyword arguments 

Why does operator.sub behave differently than int(x, [base]) ?

Answer 1

This is an implementation detail. The Python C API for extracting arguments divides between positional and keyword arguments. Positional arguments do not even have an internal name.

The code used to extract the arguments of the operator.add functions (and the like, such as sub ) is as follows:

 PyArg_UnpackTuple(a,#OP,2,2,&a1,&a2) 

As you can see, it does not contain an argument name. All code related to operator.add :

 #define spam2(OP,AOP) static PyObject *OP(PyObject *s, PyObject *a) { \ PyObject *a1, *a2; \ if(! PyArg_UnpackTuple(a,#OP,2,2,&a1,&a2)) return NULL; \ return AOP(a1,a2); } spam2(op_add , PyNumber_Add) 

 #define spam2(OP,ALTOP,DOC) {#OP, op_##OP, METH_VARARGS, PyDoc_STR(DOC)}, \ {#ALTOP, op_##OP, METH_VARARGS, PyDoc_STR(DOC)}, spam2(add,__add__, "add(a, b) -- Same as a + b.") 

As you can see, the only place where a and b are used is in docstring. The method definition also does not use the METH_KEYWORDS flag, which is necessary for accepting keyword arguments.

In general, you can safely assume that a python-based function in which you know the name of the argument will always accept keyword arguments (of course, someone could do nasty stuff with unpacking *args , but create a function doc where arguments look fine), while C functions may or may not accept keyword arguments. Most likely, functions with more than a few arguments or optional arguments take keyword arguments for later / optional ones. But you should pretty much test it.

You can find a discussion about supporting keyword arguments throughout the python-ideas mailing list. There is also an expression from Guido van Rossum (The benevolent dictator for life , known as the creator of Python):

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

I would like to see a syntax function to indicate that the argument cannot be given as a keyword argument (just as we have already added the syntax to indicate that it should be a keyword).

One area where I think adding the args keywords is directly wrong: Built-in type methods or ABC methods that are advanced. For example. consider pop () on a dict. Since the argument name is currently undocumented if someone subclasses sets and cancels this method, or if they create another mutable display class that tries to emulate a dict using duck printing, it doesn't matter what the name of the argument is for all subscribers (waiting for a dict, subclass dict or dict-like duck) will use positional arguments in the call. But if we were to document the argument names for pop (), and users started using these, most dungeons and ducks would suddenly be broken (unless they accidentally chose the same name).

Answer 2

operator is a C module that defines functions in different ways . If the function declaration in the module initialization does not include METH_KEYWORDS , the function will not accept keyword arguments under any conditions, and you will get the error indicated in the question.

Answer 3

minus(**dict(b=2, a=1)) expands to minus(b=2, a=1) . This works because your definition has argument names a and b .

operator.sub(**dict(b=2, a=1)) expands to operator.sub(b=2, a=1) . This does not work because sub does not accept keyword arguments.