[issue44019] operator.call/operator.__call__

Change by Dong-hee Na : -- pull_requests: +27418 pull_request: https://github.com/python/cpython/pull/29142 ___ Python tracker ___

[issue44019] operator.call/operator.__call__

Dong-hee Na added the comment: 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 --

[issue44019] operator.call/operator.__call__

Dong-hee Na added the comment: > 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. -- ___ Python tracker

[issue44019] operator.call/operator.__call__

Change by Dong-hee Na : -- pull_requests: +27401 pull_request: https://github.com/python/cpython/pull/29124 ___ Python tracker ___

[issue44019] operator.call/operator.__call__

STINNER Victor added the comment: test___all__ was not supposed to fail with the missing "call" in operator.__all__? -- ___ Python tracker ___

[issue44019] operator.call/operator.__call__

Dong-hee Na added the comment: 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 --

[issue44019] operator.call/operator.__call__

Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44019] operator.call/operator.__call__

Change by Kreusada : -- nosy: +Kreusada nosy_count: 7.0 -> 8.0 pull_requests: +27394 pull_request: https://github.com/python/cpython/pull/29110 ___ Python tracker ___

[issue44019] operator.call/operator.__call__

Mark Dickinson added the comment: 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 --

[issue44019] operator.call/operator.__call__

Change by Terry J. Reedy : -- nosy: +terry.reedy nosy_count: 6.0 -> 7.0 pull_requests: +26934 pull_request: https://github.com/python/cpython/pull/28551 ___ Python tracker ___

[issue44019] operator.call/operator.__call__

Mark Dickinson added the comment: Thanks for the contribution! -- stage: patch review -> resolved status: open -> closed type: -> enhancement ___ Python tracker ___

[issue44019] operator.call/operator.__call__

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

[issue44019] operator.call/operator.__call__

Antony Lee added the comment: 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

[issue44019] operator.call/operator.__call__

STINNER Victor added the comment: > `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)

[issue44019] operator.call/operator.__call__

Antony Lee added the comment: > 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

[issue44019] operator.call/operator.__call__

STINNER Victor added the comment: > 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

[issue44019] operator.call/operator.__call__

STINNER Victor added the comment: 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,

[issue44019] operator.call/operator.__call__

Mark Dickinson added the comment: This seems like a reasonable addition to me. Victor: any thoughts? -- nosy: +mark.dickinson, vstinner ___ Python tracker ___

[issue44019] operator.call/operator.__call__

Change by Antony Lee : -- keywords: +patch pull_requests: +26342 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27888 ___ Python tracker ___

[issue44019] operator.call/operator.__call__

Antony Lee added the comment: 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

[issue44019] operator.call/operator.__call__

Change by Shatabarto Bhattacharya : -- nosy: +hrik2001 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44019] operator.call/operator.__call__

New submission from Antony Lee : 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