Overloading methods in C API

[Martin v. Löwis]

"Donn Cave" <donn at drizzle.com> writes:

> Maybe it would help to consider why we're asking.  If the goal is to
> arrive at an explanation that resolves some potential confusions about
> how Python might work, I propose that "overloading" is a term we're
> better off without.

That might well be. I'm still not certain what the OP was asking.

> Isn't it reasonably true that operators in Python are a notational
> convenience for the same method dispatch that's conceptually used
> anywhere else?  

Not really. Some operators can't be represented in method calls,
e.g. "and" and "or", as they short-circuit evaluation of the
arguments.

> "a + b" is "a.__add__(b)".  

Not really.

>>> 3+4.0
7.0
>>> (3).__add__(4.0)
NotImplemented

The binary + may invoke all of the following: __add__, __radd__,
__coerce__. So these methods should be considered as helpers in
providing the meaning of the operator.

> The complications - a.__add__ may not exist, b.__radd__ may be called
> then, pages of code inside Python may be devoted to sorting out the
> possibilities - are just footnotes.  Tim Peter's explanation of why
> Python doesn't have overloading applies just the same to operators -
> lacking type declarations, there's still no way to spell it.

If you take overloading to mean "different behaviour depending on the
type of the arguments", then I do think there is a way to spell
it. It's just that the spelling doesn't involve the name of the
operator, but definitions of these helper methods.

Regards,
Martin