Overloading operators on the rigth.

[denis wendum]

In a nutshell:
What is the equivalent of __radd__ (wich overloads the right hand side
of +) when overloading the comparison operators <,>,== and so on. My
first guess __rlt__ for
overloading the rigth hand side of < did not work.
Expanded version:
In a class of numbers I have been able to overload the four arithmetic
operators +,-,* and / by defining the methods __add__ and __radd__
(etc..) in my class. This enables me to evaluate expressions
"instance_of_my _class+"instanc e_of_my_class" ,"instance + non_instance"
(with __add__) as well as "non_instance+i nstance"(with __radd__).
But my guess to define the method __rlt__ in my class in order to be
able to evaluate expressions "non_instan ce < instance" did not work.
So what are the names (if they exist at all) of the comparison operators
<,>,== and so on, when one wants to exend their rigth hand side to a
user defined (instance of a) class?

In case of direct e-mail response please remove the french translation
of nospam in my signature, that is to say the string :
pasdepourriels.

[Alex Martelli]

denis wendum <we**********@p asdepourriels.e df.fr> wrote:

But my guess to define the method __rlt__ in my class in order to be
able to evaluate expressions "non_instan ce < instance" did not work.
Sensible guess, but not the way things work.
So what are the names (if they exist at all) of the comparison operators
<,>,== and so on, when one wants to exend their rigth hand side to a
user defined (instance of a) class?

Here's how to find out:

class foo: .... def __getattr__(sel f, name):
.... print 'looking for %r' % name
.... raise AttributeError, name
.... f=foo()
12 < f looking for '__gt__'
looking for '__coerce__'
looking for '__cmp__'
True

See what's happening here? After determining that int (the type of 12)
cannot deal with comparing 12 with an instance of foo, Python's
implementation of < turns to the right hand side... and asks for a
__gt__ method first! Makes sense, because 12 < f is presumably going to
be the same thing as f > 12 ... once it doesn't find __gt__ the
implementation continues by trying to coerce f to an int (by checking if
class foo supports __coerce__) and lastly by trying for the old-style
comparison method __cmp__. But you presumably don't care about that;
rather, the gist of it is: write your __gt__ -- that will also be used
as your "__rlt__" -- and so on!
Alex

[Bengt Richter]

On Tue, 12 Oct 2004 16:06:52 +0200, al*****@yahoo.c om (Alex Martelli) wrote:

denis wendum <we**********@p asdepourriels.e df.fr> wrote:

But my guess to define the method __rlt__ in my class in order to be
able to evaluate expressions "non_instan ce < instance" did not work.

Sensible guess, but not the way things work.

So what are the names (if they exist at all) of the comparison operators
<,>,== and so on, when one wants to exend their rigth hand side to a
user defined (instance of a) class?

Here's how to find out:

class foo:... def __getattr__(sel f, name):
... print 'looking for %r' % name
... raise AttributeError, name
... f=foo()
12 < flooking for '__gt__'
looking for '__coerce__'
looking for '__cmp__'
True
See what's happening here? After determining that int (the type of 12)
cannot deal with comparing 12 with an instance of foo, Python's
implementati on of < turns to the right hand side... and asks for a
__gt__ method first! Makes sense, because 12 < f is presumably going to
be the same thing as f > 12 ... once it doesn't find __gt__ the
implementati on continues by trying to coerce f to an int (by checking if
class foo supports __coerce__) and lastly by trying for the old-style
comparison method __cmp__. But you presumably don't care about that;
rather, the gist of it is: write your __gt__ -- that will also be used
as your "__rlt__" -- and so on!

On my system, (NT4, python 2.3.2) what really happens for newstyle classes
isn't apparent from that experiment:

class foo(object): ... def __getattr__(sel f, name):
... print 'looking for %r' % name
... raise AttributeError, name
... f=foo()
12 < f True

The old style does work much the same (but note the default end result ;-)
Is that a 2.3.2 bug?
class foo: ... def __getattr__(sel f, name):
... print 'looking for %r' % name
... raise AttributeError, name
... f=foo()
12 < f

looking for '__gt__'
looking for '__coerce__'
looking for '__cmp__'
False

Regards,
Bengt Richter

[Jeff Epler]

I think it's a difference in new-style classes that __getattr__ doesn't
have a chance to run when searching for special methods.

I'm sure this is documented, but I didn't see it in
http://python.org/2.2.2/descrintro.html

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBbIUEJd0 1MZaTXX0RAgC4AJ 9VDc64p8uTr+2Rq IjDqs/wjdcN4wCgiGBs
iyu6fjYUTutHsSO BvTFE1ds=
=Cnor
-----END PGP SIGNATURE-----

[Alex Martelli]

Bengt Richter <bo**@oz.net> wrote:
...

> class foo:... def __getattr__(sel f, name): ... On my system, (NT4, python 2.3.2) what really happens for newstyle classes
isn't apparent from that experiment:

Heh, of course not -- the main difference between old-style and
new-style classes is that, for the latter, implicit lookup of special
methods when needed for operations starts with the *class*, not with the
*instance*. This is a fix of a long-standing design bug, because the
old rule was just impossible to apply consistently -- if calling X meant
looking for X.__call__ rather than X.__class__.__c all__, how could you
ever instantiate X by calling it, when X is a class whose _instances_
are meant to be callable, for example?

Since this has been discussed many times on this group, as well as in
presentations, articles, websites, books, ..., I didn't think it was
necessary to dwell on the issue again, considering it really did not
affect the answer requested by the original poster; apparently I was
wrong in so thinking. _Sigh_ -- next time somebody criticizes my posts
as being too long, I'll retort that of course they are, if I must keep
repeating such issues!-)

I just used an old-style class because, that way, I could show the
lookups happening without having to code a custom metaclass. The
special names being looked for are just the same, whether for classic or
newstyle classes, anyway -- all that changes is _where_ they're looked
up (starting on the instance, vs starting on the class).

>>> class foo(object): ... def __getattr__(sel f, name):
... print 'looking for %r' % name
... raise AttributeError, name
... >>> f=foo()
>>> 12 < f

True

The old style does work much the same (but note the default end result ;-)
Is that a 2.3.2 bug?

No bug: comparisons between objects of disparate types give essentially
arbitrary results (repeatable within one run, but, at least in theory,
potentially different among runs of the same program, I believe).
Alex

[Bengt Richter]

On Wed, 13 Oct 2004 10:18:28 +0200, al*****@yahoo.c om (Alex Martelli) wrote:

Bengt Richter <bo**@oz.net> wrote:
...

>>>> class foo:
>... def __getattr__(sel f, name): ...

On my system, (NT4, python 2.3.2) what really happens for newstyle classes
isn't apparent from that experiment:
Heh, of course not -- the main difference between old-style and
new-style classes is that, for the latter, implicit lookup of special
methods when needed for operations starts with the *class*, not with the

Well, it always starts with the class if there's no attribute on the instance,
but the key is whether the "implicit lookup" for methods needed for operations
uses an overridable __getattribute_ _ somewhere, or just chases down the bases
chain looking for the actual __gt__ or whatever, not allowing a hook to synthesize
a result.*instance*. This is a fix of a long-standing design bug, because the
old rule was just impossible to apply consistently -- if calling X meant
looking for X.__call__ rather than X.__class__.__c all__, how could you
ever instantiate X by calling it, when X is a class whose _instances_
are meant to be callable, for example?

Since this has been discussed many times on this group, as well as in
presentation s, articles, websites, books, ..., I didn't think it was
necessary to dwell on the issue again, considering it really did not
affect the answer requested by the original poster; apparently I was
wrong in so thinking. _Sigh_ -- next time somebody criticizes my posts
as being too long, I'll retort that of course they are, if I must keep
repeating such issues!-)
I have suspected you of having voice recognition input ;-)
I don't type that fast, unfortunately.
I just used an old-style class because, that way, I could show the
lookups happening without having to code a custom metaclass. The Could you show such a metaclass? I have tried a few things and not succeeded.
It almost makes me think there is no place to hook the internal __getattribute_ _
that looks for the methods for code generated from 12<f and the like.
I'd be interested in seeing it.
special names being looked for are just the same, whether for classic or ^^^^^^^^^^^^^^ but maybe not the same order, see belownewstyle classes, anyway -- all that changes is _where_ they're looked
up (starting on the instance, vs starting on the class).

>>> class foo(object):

... def __getattr__(sel f, name):
... print 'looking for %r' % name
... raise AttributeError, name
...

>>> f=foo()
>>> 12 < f

True

The old style does work much the same (but note the default end result ;-)
Is that a 2.3.2 bug?

No bug: comparisons between objects of disparate types give essentially
arbitrary results (repeatable within one run, but, at least in theory,
potentially different among runs of the same program, I believe).

I tried a class with all the methods explicit, and then removed them:

class foo(object): ... def __gt__(self, other): print 'gt'
... def __coerce__(self , other): print 'coerce'
... def __cmp__(self, other): print 'cmp'
... f=foo()
12<f gt

Ok, so it looked for __gt__ first. Remove that. del foo.__gt__ 12<f cmp
It seems to have looked for __cmp__ second, unlike in your post:

+---<from your post>------------------
Here's how to find out:
class foo: .... def __getattr__(sel f, name):
.... print 'looking for %r' % name
.... raise AttributeError, name
.... f=foo()
12 < f looking for '__gt__'
looking for '__coerce__'
looking for '__cmp__'
True +-------------------------------------

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: an integer is required
(didn't like none back from cmp, presumably)

Ok, remove __cmp__ del foo.__cmp__
One left: 12<f

coerce
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: __coerce__ didn't return a 2-tuple

NBD, but perhaps the order change is a version difference?
Not that the OP was asking any of this ;-)

Regards,
Bengt Richter

[Alex Martelli]

Bengt Richter <bo**@oz.net> wrote:

On Wed, 13 Oct 2004 10:18:28 +0200, al*****@yahoo.c om (Alex Martelli) wrote:

Bengt Richter <bo**@oz.net> wrote:
...

>>>> class foo:
>... def __getattr__(sel f, name): ...

On my system, (NT4, python 2.3.2) what really happens for newstyle classes
isn't apparent from that experiment:

Heh, of course not -- the main difference between old-style and
new-style classes is that, for the latter, implicit lookup of special
methods when needed for operations starts with the *class*, not with the

Well, it always starts with the class if there's no attribute on the instance,

I find this a strange meaning for the word "start". To ensure the
instance doesn't have the attribute, that's where (conceptually) one
could say the lookup "starts", I think.
but the key is whether the "implicit lookup" for methods needed for
operations uses an overridable __getattribute_ _ somewhere, or just chases
down the bases chain looking for the actual __gt__ or whatever, not
allowing a hook to synthesize a result.
Actually, it reaches right into the appropriate slot of the type
structure. The slots are generated or changed when the type (i.e., the
class object) is generated or changed. So, it may be improper on my
part to call this procedure a 'lookup'.

I just used an old-style class because, that way, I could show the
lookups happening without having to code a custom metaclass. The

Could you show such a metaclass? I have tried a few things and not
succeeded. It almost makes me think there is no place to hook the internal
__getattribute_ _ that looks for the methods for code generated from 12<f
and the like. I'd be interested in seeing it.

I think I'd basically have to repeat what types.ClassType is doing --
essentially, prefill all slots with functions that _do_ perform the
lookups. To be honest, I haven't tried to see if that strategy hits any
snags, I just don't think it would.

special names being looked for are just the same, whether for classic or

^^^^^^^^^^^^^^
but maybe not the same order, see below

newstyle classes, anyway -- all that changes is _where_ they're looked
up (starting on the instance, vs starting on the class).

You're right -- coercion is "fading" so it's now attempted _after_ 3-way
comparison rather than before; so the 'where' isn't quite _all_ that's
changed (I had never coded nor seen a classic class which depended on
coercion for its comparisons, which may explain though not excuse my
imprecision).

NBD, but perhaps the order change is a version difference?
Yep, it's part of coercion slowly going away.
Not that the OP was asking any of this ;-)

No, but they may still be meaningful in some cases, of course.
Alex

[Bengt Richter]

On Wed, 13 Oct 2004 10:52:57 GMT, bo**@oz.net (Bengt Richter) wrote:
[...]

NBD, but perhaps the order change is a version difference?
Not that the OP was asking any of this ;-)

Posted before recalling that the order difference showed up
on my system between old-style and new-style, both on 2.3.2,
so at least what I saw is not a version difference.

Someplace in classobject vs typeobject or such?

Regards,
Bengt Richter

[denis wendum]

Alex Martelli a écrit :

denis wendum <we**********@p asdepourriels.e df.fr> wrote:

Here's how to find out:

class foo: ... def __getattr__(sel f, name):
... print 'looking for %r' % name
... raise AttributeError, name
... f=foo()
12 < f looking for '__gt__'
looking for '__coerce__'
looking for '__cmp__'
True

See what's happening here?

Alex

Many thanks for your answer: you didn't just gave me the fish I asked but also

showed me how to use a net for catching other fish.

It seems I triggered a fierce debate with my question, but as far as I'm
concerned your example worked perfectly.

[Alex Martelli]

denis wendum <we**********@p asdepourriels.e df.fr> wrote:
...

Here's how to find out:

>> class foo: ... def __getattr__(sel f, name):
... print 'looking for %r' % name
... raise AttributeError, name
...

>> f=foo()
>> 12 < f

looking for '__gt__'
looking for '__coerce__'
looking for '__cmp__' ... Many thanks for your answer: you didn't just gave me the fish I asked but also
showed me how to use a net for catching other fish.
You're welcome! Python enjoys excellent "discoverabilit y" (a term
copiously illustrated, by explanation and by example, in Eric Raymond's
excellent book "The Art of Unix Programming", highly recommended in both
paper and free-on-the-net form) -- it shews enough of its workings,
easily enough, that it's well worth doing some sniffing around, and the
ability to hack together a 4-line class that displays things with some
print statements in an interactive session is a good example.

Of course, I _was_ being a tad too glib here, which helps explain...:
It seems I triggered a fierce debate with my question, but as far as I'm
concerned your example worked perfectly.

....the "debate", which was in fact quite friendly, even for this
community's pretty good standards. Summarizing, I half-cheated by using
an oldstyle class here, so that __getattr__ would indeed get called; a
newstyle class, while having just about the same behavior, does (...to
oversimply things a bit...) more processing at the time the class
statement is executed, it fills up a structure of internal 'slots', so
there is less "rooting around" at the time the < operator executes and
less of a chance to see the wheels in motion (there are of course plenty
of advantages in exchange, both conceptual and practical). Moreover the
'__coerce__' concept is being de-emphasized and deprecated, so the
"lookup" order shifts slightly (coercion is now tried only as a "last
ditch", after 3-way comparison with __cmp__ rather than before).

This doesn't mean you can't do "sniffing around" in newstyle classes,
but it may require a different tack, such as:

class foo(object): .... def __gt__(self, other):
.... print 'doing gt'
.... return NotImplemented
.... def __cmp__(self, other):
.... print 'doing cmp'
.... return NotImplemented
.... f=foo()
2<f doing gt
doing cmp
False

The "return NotImplemented" may be seen as a way to implement a specific
comparison (say __gt__) in some cases while punting to more generic ways
implicitly -- you may use it to indicate to Python "I don't know how to
do this specific comparison in this specific method, so please try
something else [along the usual orders in which things are tried]"...
Alex