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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4