> [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.