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

[Bengt Richter]

On Thu, 19 Dec 2002 20:56:15 -0800, Erik Max Francis <max at alcyone.com> wrote:

>Bengt Richter wrote:
>
>> Why not?
>
>Asking "Why not?" is not a very good way to get people to your side when
>yours is the marginal opinion.
>
>> They both implement the same input->output function.
>> IMO it's an artificial limitation on orthogonality not to be
>> able to pass a dict to a place that expects a function.
>
>In my opinion, this argument doesn't lead anywhere.  _Lots_ of
>interfaces take inputs and return outputs; in fact, you can argue that
>_every_ operation does this (or at least results in side effects instead
>of returning outputs).  Does that mean that every interface should be
>boiled down to a simple "do" command.
>
>Mapping and calling interfaces are analogous in some ways.  But they
>exist as separate entities _so that_ a distinction can be made.  You
                         [1]^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  ^^^
>want to eliminate that distinction.  What purpose would that serve,
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^[2]
[1] Yes!! **can** be made, not **must** be made. I want to be able
    to make distinctions too ;-) 

[2] NO!! I DON'T want to eliminate the distinction!! I don't know where
you got that impression. Perhaps there is a misunderstanding running through
this entire exchange. I don't want to do away with either [] or ().
That would be a terrible idea, obviously. I just want to be able to make
use of non-distinction when it functionally exists, and do it without an
unnecessary performance penalty. Implementation is trivial all around, but
a fast implementation is trivial in C and equally fast is impossible in Python.

I recognize that distinct interfaces are often expressed with obj() vs obj[]
and they very usefully lead to different aspects of the object. Effectively,
they are shorthand notations to specify  method search and argument setup.
They serve very well with dict, list, tuple, function, and class objects
in conventional ways that implement part of the semantics of the language.
I'm not suggesting any change to that.

But I _am_ suggesting that a dict _always_ can be viewed as a function
in a very simple, maybe even approaching formal way. Obviously I am just
manipulating representations below, but the abstract idea should be clear?

 >>> d=dict([(x,chr(x)) for x in range(ord('a'),ord('e')+1)])
 >>> d
 {97: 'a', 98: 'b', 99: 'c', 100: 'd', 101: 'e'}

 >>> def d2f(name,d):
 ...     kv = d.items()
 ...     sl = ['def %s(k):'%name,'    if k==%s: return %s'% (`kv[0][0]`,`kv[0][1]`)]
 ...     sl += ['    elif k==%s: return %s'% (`k`,`v`) for k,v in kv[1:]]
 ...     sl += ['    raise KeyError\n']
 ...     return '\n'.join(sl)
 ...
 >>> print d2f('foo',d)
 def foo(k):
     if k==97: return 'a'
     elif k==98: return 'b'
     elif k==99: return 'c'
     elif k==100: return 'd'
     elif k==101: return 'e'
     raise KeyError 

 >>> exec  d2f('foo',d)
 >>> d[99]
 'c'
 >>> foo(99)
 'c'

I see no reason not to allow expression of a dict's use in the role of
its functional twin by simply appending () instead of [], or disallowing
passing a reference to the dict where it will be interpreted in terms
of the functional twin. It is obvious that one would prefer the efficiency
of a dict over coding something like the above, but how about dealing with
an unpredictable mix where advantages go both ways? Why force an unnecessary
wrapper?

>since eliminating the distinction is utterly _trivial_ for every single
>Python programmer to do on their own if they so desire?
You impose on me type testing burdens and speed degradation for what?
It's not trivial to write something fast, and you're not talking about
a trivial **override** of an **existing** method, you're talking about
having to use suboptimum code to implement something that doesn't exist,
but that could well exist with no impact whatever on you or any other
programmer who might choose to ignore it. I don't understand your objection.

I don't understand what nerve I seem to have poked, but while I'm at it,
I may as well poke it again by saying I'd like an analogous twin function
deal for lists ;-) Anyway, ISTM the change in the status quo would go
largely unnoticed, and could not affect e.g., your programming practices
at all unless you chose to let it.

Regards,
Bengt Richter