
On Wed, Feb 4, 2009 at 10:25 AM, Brett Cannon <brett@python.org> wrote:
On Wed, Feb 4, 2009 at 05:35, Hrvoje Niksic <hrvoje.niksic@avl.com> wrote:
Andrew Bennetts wrote:
A patch to add operator.caller(*args, **kwargs) may be a good idea. Your example would then be:
map(operator.caller(), lst)
Regarding the name, note that I proposed operator.call (and operator.__call__) because it corresponds to the __call__ special method, which is analogous to how operator.neg corresponds to __neg__, operator.add to __add__, etc. The term "caller" implies creation of a new object that carries additional state, such as method name in operator.methodcaller, item in operator.itemgetter, or attr in operator.attrgetter.
Part of the problem is the term 'call' is an overloaded term. Do you really mean only objects that define __call__? What about objects that define __init__ and thus can be called as well? If you mean the former than you have to make sure the docs are very clear about this; there is a reason we got rid of callable(). If you mean the latter then there is little benefit to the function since ``[x() for x in lst]`` gets you the same result as your map call.
Not sure I follow you here. It's not the __init__ that allows you to do ``x()``, it's the fact that the class declares a __call__, right?
class C(object): ... pass ... C.__call__() <__main__.C object at 0x01A3C370> C() <__main__.C object at 0x02622EB0> str.__call__() '' str() ''
That said, I'm also unconvinced of the utility of operator.call over the equivalent list comprehension. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy