Another try at Python's selfishness

[n.estner at gmx.de]

Donn Cave wrote:

> Quoth n.estner at gmx.de:
> | > Still see no problem.  Of course, it goes without saying that
> | > Python 2.4 doesn't work this way, but given that it's theoretically
> | > possible for f(a) to be resolved similarly to a.f, then I really
> | > do not see what you're seeing here.  The kwargs parameter appears
> | > irrelevant from where I'm sitting.
> |
> | Then either you didn't understand my answers, or I didn't understand
> | your idea. Could you summarize how exactly "f(x,y=z)" should be
> | resolved, i.e. where it should look for "f"?
>
> a.f ==> f(a)

So, if the compiler recognizes the tokens "a.f", it should treat them
as if it found the tokens "f(a)". But that wouldn't do what you want.
You want it to do something different if it found the tokens "f(a)".

> I would agree that I didn't understand your answers, but they weren't
> really answers so much as questions, along the lines of ``well then,
> how would this work?''  I seem to have missed what you were driving at,
> but maybe if you were to just came out and explain the point?

You do know what a rethorical question is?

The first point is: Python has global functions, as well as methods. If
f(a) should look up f inside a first, that would shadow any global or
local f. That's bad, because python is dynamically typed, and you
sometimes down' know what "a" is. Things like "open(filename)" or
"tuple(a,b,c)" could behave completely unexpected, if "filename" had an
"open" or "a" a "tuple" attribute.

The other point is: Python supports named arguments. The algorithm to
put positional and named arguments into the right parameters is rather
tricky, and it _must_ know the function that's being called to work.
So, you simply can't make function lookup depend on the parameters,
it's a hen-egg problem.

> Of course the whole business is kind of a joke, since there is no way
> anyone in their right mind would wish to change Python's notation for
> such trivial reasons, but there actually are languages that resolve
> functions based on argument types.  Overloading in C++ is somewhat
> like this, Haskell's typeclass mechanism, and there is a ``multiple
> dispatch'' model that I have no experience with but is not without its
> supporters.

Yes, but both C++ and Haskell are statically typed, and neither
supports named arguments.
(We're talking about one function operating on one object, so I don't
see what multiple dispatch has to do with this)