Re: Overloading function calls

Tim Peters (tim@ksr.com)
Tue, 07 Jun 94 14:16:25 -0400

> > [under a simpler scheme, how does e.g. Complex / Date signal an error?]

> [guido]
> ... Date.__div__ sees the swapped flag and knows that the unswapped
> operation has already been tried.

Agree that for invocations originating _from_ Python, that's reliable.
For direct user-written invocations, it may or may not be true -- but it
could be a violate-at-your-own-risk convention.

> In general I'm wary of routines that take flags (such as 'swapped')
> that really mean "use a different version of the function" -- these
> flags are almost always passed from constants and so it would be more
> efficient to have a second name for the variant function.

The "swapped" flag does suck! I don't care so much about the efficiency
of rare cases, as the dirtiness of the design.

> So my counter proposal would be to define __rbinop__ for every binop
> where the RHS wants control.

I agree that's a better design. Think it does imply that, for writing
general numeric classes, each LHS method needs to look like:

def __binop__(x, y):
if y has a type I know about:
do it & return
# don't know how to handle y
if hasattr(y, '__rbinop__'):
return y.__rbinop__(x)
else:
raise TypeError, etc

and each RHS method like

def __rbinop__(y, x):
if x has a type I know about:
do it & return
raise TypeError, etc

The intent is to allow new classes to be defined that work with old
classes, without needing to alter the old classes, and part of the
programming convention to support that is that "reversed" methods assume
the unreversed operation isn't possible.

Ya, I could live with that.

if-you-can-call-this-living<wink>-ly y'rs - tim

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

ps: Is _anyone_ concerned about the lack of backward compatibility? I'm
not.