Question

So I have a one liner:

import decimal; h = decimal.Decimal('100.0'); (h > .01, h < .01, h.__gt__(.01), h.__lt__(.01))

All it does is make a Decimal object holding 100.0, and compares it to .01 (the float) in various ways.

My result is:

>>> import decimal; h = decimal.Decimal('100.0'); (h > .01, h < .01, h.__gt__(.01), h.__lt__(.01))
(False, True, NotImplemented, NotImplemented)

From the docs: “A rich comparison method may return the singleton NotImplemented if it does not implement the operation for a given pair of arguments.”

So really there are three questions here.

1. When a rich comparison method returns NotImplemented, what happens? Why doesn’t it raise an Exception?

2. When it gets NotImplemented, why does it return False in the first case, and True in the second? bool(NotImplemented) should be a constant.

3. Does it simply fall back to id() checking? It seems no (or yes, but backwards):

(ignore this line, formatting is screwed up and this fixes it)

from decimal import Decimal
h = Decimal('100.0')
f = .01
print h < f, id(h) < id(f)
print h > f, id(h) > id(f)

My results were tested on:

Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on win32
Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on win32

Edit: Documentation about ordering: http://docs.python.org/library/stdtypes.html#comparisons

Answer 1

When a rich comparison method returns
NotImplemented, what happens? Why
doesn’t it raise an Exception?

it delegates to the converse method (e.g., __lt__ when the operator is >) RHS in the comparison (the float) — which in this case also returns NotImplemented — and finally falls back to Python 2’s silly old rules for heterogeneous comparisons.

When it gets NotImplemented, why does
it return False in the first case, and
True in the second?
bool(NotImplemented) should be a
constant.

No bool involved — since both sides of the comparison return NotImplemented (due to a deliberate design decision to NOT support any operation between decimals and floats), the silly old rules are used as a fallback (and in a recent-enough version will be comparing the types, not the instances — id has nothing to do with it, therefore). In Python 3, such an unsupported heterogeneous comparison would fail, and raise a clear exception, but in Python 2, for backwards compatibility, that just can’t happen — it must keep behaving in the silly way it’s behaved throughout Python 2’s lifetime.

Introducing backwards incompatibilities to fix what are now considered design errors, like this part about het comparisons, was the core reason to introduce Python 3. As long as you’re sticking to Python 2 (e.g. because it has more third party extensions, etc), you need to grin and bear with these imperfections that are fixed in Python 3 only.