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