itemgetter(), attrgetter() and methodcaller() objects require one argument. They raise TypeError if less or more than one positional argument is provided. But they totally ignore any keyword arguments.>>> import operator>>> f = operator.itemgetter(1)>>> f('abc', spam=3)'b'>>> f = operator.attrgetter('index')>>> f('abc', spam=3)<built-in method index of str object at 0xb7172b20>>>> f = operator.methodcaller('upper')>>> f('abc', spam=3)'ABC'Proposed patch makes these objects raise TypeError if keyword arguments are provided.

Seems sensible for itemgetter and attrgetter, where all but the first argument is nonsensical anyway.It really seems like methodcaller should allow additional arguments (positional and keyword though), a la functools.partial (the difference being the support for duck-typed methods, where functools.partial only supports unbound methods for a specific type). I suppose#25454 disagrees, but it seems very strange how `methodcaller` is like `functools.partial`, but without call time argument binding, only definition time.

This makes sense. It makes the C version and Python version consistent.

> It really seems like methodcaller should allow additional arguments (positional and keyword though)This is good argument for raising an exception. Wrong expectations can lead to incorrect code.

This seems like a good change, and the patch looks correct.

New changeset16461a0016bf by Serhiy Storchaka in branch '3.5':Issue#26822: itemgetter, attrgetter and methodcaller objects no longerhttps://hg.python.org/cpython/rev/16461a0016bfNew changeset9b565815079a by Serhiy Storchaka in branch '2.7':Issue#26822: itemgetter, attrgetter and methodcaller objects no longerhttps://hg.python.org/cpython/rev/9b565815079aNew changeset5faccb403ad8 by Serhiy Storchaka in branch 'default':Issue#26822: itemgetter, attrgetter and methodcaller objects no longerhttps://hg.python.org/cpython/rev/5faccb403ad8

In general there should be an early out test for keywords==NULL before calling the comparatively high overhead function _PyArg_NoKeywords.  That function adds overhead everywhere it is used and provides zero benefit to correct programs in order to provide earlier detection of a very rare class of errors.Some care needs to be taken before slapping _PyArg_NoKeywords onto every function in the core that doesn't use keyword arguments.

Here is a patch that adds fast checks before calling _PyArg_NoKeywords().Other option is redefine _PyArg_NoKeywords as a macro:#define _PyArg_NoKeywords(name, kw)  ((kw) != NULL && _PyArg_NoKeywords((name), (kw)))This will affect all usages of _PyArg_NoKeywords.

The patch looks good and is ready to apply.  The macro also is a fine idea.

New changeset54663cbd0de1 by Serhiy Storchaka in branch '3.5':Issue#26822: Decreased an overhead of using _PyArg_NoKeywords() in calls ofhttps://hg.python.org/cpython/rev/54663cbd0de1New changeset22caee20223e by Serhiy Storchaka in branch 'default':Issue#26822: Decreased an overhead of using _PyArg_NoKeywords() in calls ofhttps://hg.python.org/cpython/rev/22caee20223eNew changesetd738f268a013 by Serhiy Storchaka in branch '2.7':Issue#26822: Decreased an overhead of using _PyArg_NoKeywords() in calls ofhttps://hg.python.org/cpython/rev/d738f268a013

Upon closer inspection, redefine _PyArg_NoKeywords as a macro turned out to be not such a good idea. Other use of _PyArg_NoKeywords are in __new__ and __init__ methods. Create these objects in most cases (except may be slice) is performance critical operation than calling itemgetter, attrgetter or methodcaller object. It is better to add this microoptimization on cases (set and frozenset already have it).

-    if (!_PyArg_NoKeywords("itemgetter", kw))+    if (kw != NULL && !_PyArg_NoKeywords("itemgetter", kw))Can't we use a macro to implement this micro-optimization, instead of modifying each call to _PyArg_NoKeywords?

> Can't we use a macro to implement this micro-optimization, instead of modifying each call to _PyArg_NoKeywords?I proposed this idea above. But then I have found that 1) most usages of _PyArg_NoKeywords are not in performance critical code and 2) my attempt caused a crash. Thus I have committed simpler patch.

> 2) my attempt caused a crash.I found an error in my attempt. Here is a patch that correctly define macros for _PyArg_NoKeywords and _PyArg_NoPositional micro-optimization.I don't know wherever it is worth to push it.

Seems I missed to attach a patch. Openedissue29460 for this tweak.