-
-
Notifications
You must be signed in to change notification settings - Fork 30.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
operator.call/operator.__call__ #88185
Comments
Adding a call/call function to the operator module (where 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 |
Actually, upon further thought, the semantics I suggested above should go into |
This seems like a reasonable addition to me. Victor: any thoughts? |
Python 2.7 had apply(func, args, kwargs) which called func(*args, **kwargs). There is also functools.partial(func, *args, **kwargs)(*args2, **kwargs2) which calls func(*args, *args2, **kwargs, **kwargs2). operator.methodcaller(name, /, *args, **kwargs)(obj) calls getattr(obj, name)(*args, **kwargs). 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 |
Can't you use functools.partial() for that? |
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
Agreed; on the other hand function calling is much more intrinsic(?!)
How do you propose to do that? Perhaps I am missing an easy solution... |
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). |
Thanks for the contribution! |
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. |
I'd really like to use this in python 3.7. Any chance there is a python package available which backports this? |
def call(obj, /, *args, **kwargs):
"""Same as obj(*args, **kwargs)."""
return obj(*args, **kwargs)
__call__ = call |
@terryjreedy Thanks! I have a python implementation already but it is a little slower than I'd like so I was hoping the c implementation in the operator module might be a little faster. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: