[Python-Dev] Missing operator.call

[Steven Bethard]

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