[issue25454] operator.methodcaller should accept additional arguments during the call

2015-10-30 Thread Raymond Hettinger

Raymond Hettinger added the comment:

Closing this for the reasons mentions above.

--
resolution:  -> rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25454] operator.methodcaller should accept additional arguments during the call

2015-10-27 Thread Raymond Hettinger

Raymond Hettinger added the comment:

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.

--
assignee:  -> rhettinger
priority: normal -> low

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25454] operator.methodcaller should accept additional arguments during the call

2015-10-27 Thread Josh Rosenberg

Josh Rosenberg added the comment:

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.

--
nosy: +josh.r

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25454] operator.methodcaller should accept additional arguments during the call

2015-10-25 Thread Raymond Hettinger

Raymond Hettinger added the comment:

This would be easier to evaluate propertly if you supplied some meaningful use 
cases.  Otherwise, it is looks like hypergeneralizing.

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25454] operator.methodcaller should accept additional arguments during the call

2015-10-25 Thread Evgeny Kapun

Evgeny Kapun added the comment:

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:

reduce(methodcaller("combine"), objs) # reduce a sequence using "combine" 
method
map(methodcaller("combine"), alist, blist) # combine pairs of elements
all(map(methodcaller("compatible_with"), alist, blist)) # check that pairs 
of elements are compatible

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25454] operator.methodcaller should accept additional arguments during the call

2015-10-21 Thread Evgeny Kapun

New submission from Evgeny Kapun:

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

--
components: Extension Modules
messages: 253307
nosy: abacabadabacaba
priority: normal
severity: normal
status: open
title: operator.methodcaller should accept additional arguments during the call
type: enhancement
versions: Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com