[Python-Dev] Missing operator.call (original) (raw)

Steven Bethard steven.bethard at gmail.com
Wed Feb 4 19:43:25 CET 2009

On Wed, Feb 4, 2009 at 10:25 AM, Brett Cannon <brett at python.org> wrote:

On Wed, Feb 4, 2009 at 05:35, Hrvoje Niksic <hrvoje.niksic at 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

More information about the Python-Dev mailing list