Builtin dict should be callable, since a dict defines a function

[Bengt Richter]

On Fri, 20 Dec 2002 13:16:24 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <martin at v.loewis.de> wrote:

>Bengt Richter wrote:
>> I recognize that distinct interfaces are often expressed with obj() vs obj[]
>> and they very usefully lead to different aspects of the object. 
>
>Not to mention "obj." Every object is a function, too, taking its 
>attributes as arguments and returning a value (or AttributeError).
>
Sure, most everything you can do with anything has a .__xxx__(...) spelling.
(Easy to say now ;-)

>Your misconception is that you want to make one functional access to an 
>object the preferred one. This is confusing:
Not to be confrontational, but what gives you the idea that I want
to make it preferred? Or do I miss your meaning? No,  I think adict[key]
will be preferable most of the time. I was just forgetting that
adict.__getitem__(key) functionally spells what I wanted to spell with adict(key),
and I can pass the bound method/method wrapper object where I wanted to
pass the dict itself. Even so, I still don't see the objection to
the nicer spelling, since that syntax is not doing anything by default.
>
>In the face of ambiguity, refuse the temptation to guess.
>There should be one-- and preferably only one --obvious way to do it.
That can cut both ways ;-) Since a dict and a function both have sensible
function interpretations, we shouldn't have to write

    a=foo(dct.__getitem__); b=foo(fcn)

where sensible thing is to use "one way"(tm) to write both calls ;-)

    a=foo(dct); b=foo(fcn)

where e.g.,
    def foo(obj): return obj()
    
>
>IOW, why should d(key) be the same as d.__getitem__(key), instead of,
>say, d.get(key); the latter has even the advantage of being a total 
One defines a (non-exception-raising) function mapping finite sets 1:1,
the other maps the rest of the universe to any selected element of the
universe as well. ISTM the simpler is the more natural default, plus the
second mapping definition is not defined by the object, but effectively
added by the caller at each call time, except for the default default of None.


>function. This also points to a solution to your original question: If 
>you have a dictionary and need a callable, use d.__getitem__.
>
Well, that last was pretty much a touché & d'oh, Martin, although Holger
beat you to it by an hour and twenty minutes ;-)

But I still would ask the question, "Why should an object which has an
unambiguous, simple, sensible, intuitively obvious functional
interpretation refuse to be called as a function (i.e., provide the
__call__ method wrapper) if this is not already defined ?"
I would think that's in the spirit of unification, not anarchy ;-)

Further, I would be looking for any really sensible uses of existing
"trailer" notation with respect to any standard object. E.g., [i:j]
might seem weird on a function object, but what about a generator?

Regards,
Bengt Richter