Overloading function calls

Tim Peters (tim@ksr.com)
Fri, 27 May 94 23:54:54 -0400

Several people just spontaneously suggested (or in Steve M's case,
resuggested) allowing overloading of the function-call notation.

I certainly like that too, and-- lost among the Syntax Wars --posted
earlier this week about several (at least perceived) problems with
overloading other operators.

These all tie together: I suspect the real reason function-call
notation wasn't overloadable from the start is the same reason the
operators that are overloadable are full of surprises (for a sample of
which see the earlier posting): Python _believes_ that when you're
overloading operators, your class must be trying to mimic a sequence,
mapping, or numeric type. That assumption is even built in to the
organization of section 3.3 ("Special method names") of the Reference
Manual. So, e.g., since none of the built-in flavors of those types
supports a function-call notation, there was no provision for overloading
it; and since among built-in types "<<" is only defined for numeric
types, any class that wants to overload "<<" has to wrestle with the
__coerce__ method (whether or not _you_ think your class is "numeric");
and so on.

Is this a case where making the language _dumber_ would help more people
than it hurt? I've hesitated to suggest a concrete alternative because I
can't think of a reasonable one that's completely backward compatible.
But many of the rules now aren't documented, and it's hard to believe
they were all intentional anyway <wink>, so maybe backward compatibility
isn't so important here?

underloadedly y'rs - tim

Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp