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

[Bengt Richter]

On Thu, 19 Dec 2002 18:17:03 -0800, Erik Max Francis <max at alcyone.com> wrote:

>Bengt Richter wrote:
>
>> I posted the suggestion in a thread  Re: case-insensitive and
>> internationalized sort,
>> but it occurs to me that the principle is arguable from the abstract
>> point of view.
>> I.e., a dict implements a function key -> value, so why not let it
>> accept a normal
>> function arg list (i.e., the tuple) as the argument for its key ->
>> value function?
>> It should be a pretty simple change to provide __call__(self, *args):
>> return self[args]
>> under the hood, and let hashability chips fall where they will via [].
>
>But why would this be helpful?  A dictionary implements a mappable
>interface; a function implements are callable interface.  They're
>different interfaces; why would dovetailing them into the same interface
>be beneficial?
You can pass a reference to a dict to something that expects a function,
e.g., a sort. You could pass it as a memoized-result proxy function in
some context and catch KeyError to take care of LRU caching update, etc.
I'm sure many uses would turn up once the obstacle was removed, and
people thought of functions as mappings and vice versa ;-)
>
>It's a simple change, sure, but furthermore it's trivial enough for you
>to implement it yourself in a subclass of dict.
Yes (as I mentioned less specifically ;-) But not without the performance
hit of an extra layer.

I think a dict abstractly does define a function, so IMO it would be a good
thing to allow access to it to be spelled that way. If you want to override
__call__ in a subclass, fine, but let the base class provide a way to
spell the natural default. A mapping is a function, and vv. ;-)

Regards,
Bengt Richter