Adding a call/__call__ function to the operator module (where `operator.call(*args, **kwargs)(func) == func(*args, **kwargs)`, similarly to operator.methodcaller) seems consistent with the design with the rest of the operator module.

An actual use case I had for such an operator was collecting a bunch of callables in a list and wanting to dispatch them to concurrent.futures.Executor.map, i.e. something like `executor.map(operator.call, funcs)` (to get the parallelized version of `[func() for func in funcs]`).

Actually, upon further thought, the semantics I suggested above should go into `operator.caller` (cf. `operator.methodcaller`), and `operator.call`/`operator.__call__` should instead be defined as `operator.call(f, *args, **kwargs) == f(*args, **kwargs)`, so that the general rule `operator.opname(a, b) == a.__opname__(b)` (modulo dunder lookup rules) remains applicable.

This seems like a reasonable addition to me. Victor: any thoughts?

Python 2.7 had apply(func, args, kwargs) which called func(*args, **kwargs).
https://docs.python.org/2.7/library/functions.html#apply

There is also functools.partial(func, *args, **kwargs)(*args2, **kwargs2) which calls func(*args, *args2, **kwargs, **kwargs2).
https://docs.python.org/dev/library/functools.html#functools.partial

operator.methodcaller(name, /, *args, **kwargs)(obj) calls getattr(obj, name)(*args, **kwargs).
https://docs.python.org/dev/library/operator.html#operator.methodcaller

I'm not convinced that operator.caller() would be useful to me. Why do you consider that it belongs to the stdlib? It is a common pattern? Did you see in this pattern in the current stdlib?

Can't you easily implement such helper function in a few lines of Python?

operator documentation says: "The operator module exports a set of efficient functions corresponding to the intrinsic operators of Python". I don't see how operator.caller() implements an existing "intrinsic operators of Python".

methodcaller() can be implemented in 4 lines of Python, as shown in its documentation:
---
def methodcaller(name, /, *args, **kwargs):
    def caller(obj):
        return getattr(obj, name)(*args, **kwargs)
    return caller
---

> An actual use case I had for such an operator was collecting a bunch of callables in a list and wanting to dispatch them to concurrent.futures.Executor.map, i.e. something like `executor.map(operator.call, funcs)` (to get the parallelized version of `[func() for func in funcs]`).

Can't you use functools.partial() for that?

> I'm not convinced that operator.caller() would be useful to me.

To be clear, as noted above, I have realized that the semantics I initially proposed (now known as "caller") are not particularly useful; the semantics I am proposing (and implementing in the linked PR) are `call(f, *args, **kwargs) == f(*args, **kwargs)`.

> I don't see how operator.caller() implements an existing "intrinsic operators of Python".

Agreed; on the other hand function calling is much more intrinsic(?!)

> Can't you use functools.partial() for that?

How do you propose to do that?  Perhaps I am missing an easy solution...

> `call(f, *args, **kwargs) == f(*args, **kwargs)`

So you can want to reintroduce the Python 2 apply() function which was removed in Python 3.

You can reimplement it in 2 lines, no?

def call(func, *args, **kwargs):
  return func(*args, **kwargs)

Python2's apply has different semantics: it takes non-unpacked arguments, i.e.

    def apply(f, args, kwargs={}): return f(*args, **kwargs)

rather than

    def call(f, *args, **kwargs): return f(*args, **kwargs)

I agree that both functions can be written in two (or one) line, but the same can be said of most functions in the operator module (def add(x, y): return x + y); from the module's doc ("efficient functions corresponding to the intrinsic operators"), I would argue that the criteria for inclusion are efficiency (operator.call is indeed fast, see the linked PR) and intrinsicness (I don't know if there's a hard definition, but function calling certainly seems intrinsic).

New changeset 6587fc60d447603fb8c631d81d9bb379f53c39ab by Antony Lee in branch 'main':
bpo-44019: Implement operator.call(). (GH-27888)
https://github.com/python/cpython/commit/6587fc60d447603fb8c631d81d9bb379f53c39ab

Thanks for the contribution!

New changeset bfe26bbad787c124f0ce144cff1b513ef9d2dc9c by Terry Jan Reedy in branch 'main':
bpo-44019: Add missing comma to operator.call doc (GH-28551)
https://github.com/python/cpython/commit/bfe26bbad787c124f0ce144cff1b513ef9d2dc9c

New changeset a53456e587c2e935e7e77170d57960e8c80d8a4d by Kreus Amredes in branch 'main':
bpo-44019: Add operator.call() to __all__ for the operator module (GH-29110)
https://github.com/python/cpython/commit/a53456e587c2e935e7e77170d57960e8c80d8a4d

test___all__ was not supposed to fail with the missing "call" in operator.__all__?

> test___all__ was not supposed to fail with the missing "call" in operator.__all__?

AFAIK, it doesn't check.

I add the test for the operator module.

New changeset 37fad7d3b7154c44b9902a2ab0db8641f1a0284b by Dong-hee Na in branch 'main':
bpo-44019: Add test_all_exported_names for operator module (GH-29124)
https://github.com/python/cpython/commit/37fad7d3b7154c44b9902a2ab0db8641f1a0284b