I'm swinging around to the view that it's best if the interpreter do as
little as possible to get 2-argument special-method RHS dispatch to work
at all. Then, if a later extension (e.g., multi-methods <wink>) is
adopted that provides a clean way of doing this regardless of arity or
"specialness", the extension will have little overlapping existing
magical machinery to fight against and/or mimic and/or worry about. In
the meantime, we can at least get the commonest cases to work without
much pain.
Marc, do note that Guido's proposal is enough of a change so that we
_could_ adopt a uniform
def __binop__(x,y): return binop_handler(x,y)
def __rbinop__(y,x): return binop_handler(x,y)
coding style and implement whatever type-registration scheme people like
in binop_handler.
Guido, nobody in public or private has expressed any love for the more-
elaborate __coerce__/__rcoerce__/swapped scheme, and I'm not in love with
it either, so if it's OK by you let's drop it.
One issue then remains: what to do about the current __coerce__ method?
A compatible scheme would treat it like all the other binops (so
__rcoerce__ would be introduced), keeping its present meaning (return a
2-tuple coerced to a common type if possible, else None), but restricting
its invocation to explict "coerce" calls (i.e., no longer called by magic
in contexts other than implementing explicit coercion).
A clear but incompatible alternative is to drop __coerce__. When it was
invoked by magic to accomplish a mixture of coercions and RHS dispatch,
it had a clear (well, vital <grin>) place in the overall scheme; not sure
it has a clear job to do post-change. I'd probably nuke it & see if
anyone gripes.
evidence-so-far-sez-you-could-nuke-*all*-the-binops-without-triggering-
a-revolution<0.9-grin>-ly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp