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.methodcaller should accept additional arguments during the call #69640
Comments
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:
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. |
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: