bpo-44019: Implement operator.call().

[anntzer]

Having operator.call(obj, arg) mean type(obj).__call__(obj, arg) is
consistent with the other dunder operators. The semantics with *args, **kwargs then follow naturally from the single-arg semantics.

---

I realize that I proposed different semantics in the original bug report, but that didn't even actually match to the proposed use case; the second proposal in the thread is the correct one. The semantics here work for at least two different use cases that I have seen:

• Using concurrent.futures.Executor.map on a list of callables (executor.map(operator.call, callables)). In that case the performance doesn't actually matter much and a Python helper would in fact be fine.

• Loading a "typed" csv file (cf. numpy.loadtxt), where each column has a separate type, e.g.

converters = [int, float, int, float]
lines = [  # Assume that we already `str.split` them.
    ["1", "2.2", "3", "4.4"],
    ["5", "6.6", "7", "8.8"],
]
[[*map(operator.call, converters, words)] for words in lines]
# faster than the list comprehension
[[conv(word) for conv, word in zip(converters, words)] for words in lines]

Here the performance actually matters (with numpy, one may easily be loading millions of rows). A simple benchmark gives

$ ./python -mtimeit -s 'from operator import call; funcs = [int, float, float, int]; inputs = ["1", "2", "3", "4"]' -- '[*map(call, funcs, inputs)]'
500000 loops, best of 5: 761 nsec per loop
$ ./python -mtimeit -s 'from operator import call; funcs = [int, float, float, int]; inputs = ["1", "2", "3", "4"]' -- '[func(inp) for func, inp in zip(funcs, inputs)]'
200000 loops, best of 5: 1.07 usec per loop

i.e. map(operator.call, ...) gives a significant speedup.

https://bugs.python.org/issue44019

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[anntzer]

From my side, this is ready to go, afaict.

[vstinner]

Please add / to the prototype.

Suggested change

	.. function:: call(obj, *args, **kwargs)
	.. function:: call(obj, /, *args, **kwargs)

[anntzer]

done, thanks for noticing.

[merwok]

The user experience isn’t good for reviewers when history is rewritten in a PR, so please do regular commits and pushes for CPython (see https://devguide.python.org/pullrequest/#submitting)

[vstinner]

LGTM. The implementation is correct. I'm not convinced of the usefulness of this change, but the benchmark is interesting. I let other core dev merging the change :-)

[anntzer]

Apologies for the squash commit, I did not realize this was the policy here.

[mdickinson]

LGTM. This seems like a fairly natural addition to the operator module for me.

[mdickinson]

Do we need a "what's new" entry for this?

[anntzer]

There's a NEWS.d entry, did you mean anything else?

[mdickinson]

@anntzer: I meant the https://github.com/python/cpython/blob/main/Doc/whatsnew/3.11.rst file. I think it's worth a mention there (following the guidelines in https://devguide.python.org/committing/?highlight=what%27s%20new#updating-news-and-what-s-new-in-python).

[vstinner]

Ah yes please, document the addition in What's New in Python 3.11.

[anntzer]

Done.

[vstinner]

Done.

I don't see any change on Doc/whatsnew/3.11.rst.

[anntzer]

https://github.com/python/cpython/pull/27888/files#diff-78f24041d66ab8ed2ae1aee94bcd42396d27af833cb96a3c506294c6d6dce82d?

[vstinner]

Suggested change

	* A new function ``operator.call`` has been added, such that
	``operator.call(obj, *args, **kwargs) == obj(*args, **kwargs)``.
	(Contributed by Antony Lee in :issue:`44019`.)
	* A new function ``operator.call`` has been added, such that
	``operator.call(obj, *args, **kwargs) == obj(*args, **kwargs)``.
	(Contributed by Antony Lee in :issue:`44019`.)

[anntzer]

woopsie, thanks, fixed.

[vstinner]

LGTM. I let another core dev merge this PR.