Currently, operator.methodcaller behaves like this:

    def methodcaller(name, *args, **kwargs):
        def caller(obj):
            return getattr(obj, name)(*args, **kwargs)
        return caller

That is, it is possible to supply arguments when the object is created but not during the call. I think that it will be more useful if it behaved like this:

    def methodcaller(name, *args, **kwargs):
        def caller(obj, *args2, **kwargs2):
            return getattr(obj, name)(*args, *args2, **kwargs, **kwargs2)
        return caller

This would be easier to evaluate propertly if you supplied some meaningful use cases.  Otherwise, it is looks like hypergeneralizing.

There are methods that accept a single argument and behave like a binary operation or a predicate. It would be useful to be able to turn them into binary functions for use with higher-order functions like map and reduce:

    reduce(methodcaller("combine"), objs) # reduce a sequence using "combine" method
    map(methodcaller("combine"), alist, blist) # combine pairs of elements
    all(map(methodcaller("compatible_with"), alist, blist)) # check that pairs of elements are compatible

This functionality is already available for overloaded operators, because operator module provides them as functions. Some methods behave similarly to operators, so I think that a similar functionality should be available for them as well.

I could see the argument for this to make methodcaller more like an unbound version of functools.partial. Partial lets you prebind some things and not others, you might want to do the same thing with methods, where you prebind the method name and some arguments, but dynamically bind the instance and some additional arguments.

I would rather leave lambda or plain function definitions as the way to handle any cases not covered by itergetter, attrgettr, and methodcaller.   It feels like we're working way too hard to produce more ways to do it.   

Also, the suggested use cases with all() and map() would likely be expressed more cleanly (and readably) with a list comprehension.  The reduce() example isn't clear at all (that is part of the reason it was banished to the functools module).  I would not want to encounter any of the examples during a debugging session.

I think we should decline this feature request as being "a bridge too far" and not what the zen-of-python would encourage us to do.  I can't think of any existing code that would be improved by the availability of this extension.  Instead, we ought to focus on making the core language as expressive as possible.

Closing this for the reasons mentions above.