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

[Martin v. Löwis]

bokr at oz.net (Bengt Richter) writes:

> >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? 

Your message <atttql$ouf$0 at 216.39.172.122> indicated so. You wrote

# __call__(self, *args): return self[args]

So you want d.__call__ to be the same as d.__getitem__. I was asking
why it shouldn't be 

 def __call__(self, *args):
   return self.get(args)

I.e. d.__call__ = d.__get__

Both are meaningful calling interfaces for the function defined by the
dictionary, yet you prefer one of these two options over the other.

> Even so, I still don't see the objection to the nicer spelling,
> since that syntax is not doing anything by default.

My objection is that such a spelling should have an obvious meaning,
i.e. that one should refuse the temptation to guess. It is not obvious
to me why __getitem__ is better than get.

> 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

I question that the exception-raising one is the simpler one. From a
functional point, exception raising is a difficult issue, functions
are conceptually always total.

> 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 ?"

Can't answer this question in general. In the specific case, there is
an easy answer: There is no unambiguous functional interpretation for
dictionaries.

Regards,
Martin