Greg Ward wrote:
Hi all --
looks like ExtensionClass doesn't recognize/implement the '__radd__()' protocol. Speculation below; first, a demonstration. Normal case: a regular class Number that knows how to add itself to other number-like things:
(demonstration snipped)
Speculation time: I'm guessing that this is similar to the problem with 'isinstance()' and ExtensionClass that I found several months ago, which was heroically debugged by Barry. To recap, it's a mutual finger-pointing bug: Python (Guido) can claim that it's up to ExtensionClass (Jim) to emulate the full semantics of Python classes/instances, but ExtensionClass can claim that Python should be more relaxed in what it accepts as a "class object" or "instance object".
I think the relevant code in Python is in Objects/abstract.c, specifically 'PyNumber_Add()' and the BINOP macro:
#define BINOP(v, w, opname, ropname, thisfunc) \ if (PyInstance_Check(v) || PyInstance_Check(w)) \ return PyInstance_DoBinOp(v, w, opname, ropname, thisfunc)
[...] PyNumber_Add(v, w) PyObject *v, *w; { PySequenceMethods *m;
BINOP(v, w, "__add__", "__radd__", PyNumber_Add); [...]
My guess is that PyInstance_Check() returns false for ExtensionClass instances. Two possible fixes: loosen up PyInstance_Check(), or loosen up BINOP.
Well, it's a nice theory. It doesn't explain why '__add__()' works for ExtensionClass while '__radd__()' does not; perhaps ExtensionClass implements that much of Python's class semantics, but doesn't go as far as '__radd__()'.
I'd love to see __radd__ added. ;) I don't remember why it's not there. Maybe I was just lazy. It may be fairly hard to add. I haven't looked in quite a while. As anyone whos looked at ExtensionClass sources may be able to tell, ExtensionClass has to play quite a few tricks to: - Try to sanely bridge the quite different semantics of Python "types" and "classes" (e.g. there's no radd for "types"). - Try to overcome the fact that the interpreter special-cases InstanceType and ClassType pretty liberally. To (try to and mostly succeed to) provide instance semantics I have to do alot of weird indirection. This is especially hard for numeric things. Your analysis of the code demonstrates this issue. ExtensionClass instances are not of type InstanceType. In fact, each ExtensionClass is a separate type and instances of different ExtensionClasses have different types. Note that I just got around to responding to your earlier post "Comparison inconsistency with ExtensionClass". This has a similar root cause: the special-case treatment of InstanceType. I think that the *real* solution to this problem is to get rid of ExtensionClass. ;) To do this, I need to get the features I have in ExtensionClass into Python. I guess there's some hope for that in Python 3K (love that name :). In the mean time, I don't have time to fix the radd problem myself, but would be willing to advise someone who wanted to try to take it on, especially if we could work out some phone or face-to-face sessions. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.