views:

80

answers:

2

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

A: 

I have Python 2.6.4 and your example works fine, i.e., I find

(True, False, NotImplemented, NotImplemented)

which is expected. I don't know why you obtain different results.

About id: id has nothing to do with comparisons, so under no circumstances should you compare a and b by id(a) < id(b), that does not make any sense. id is a bit like an adress in memory, so comparing them makes no sense at all.

Olivier
id() is used as a last resort to sort objects if the objects don't define their own comparisons. I don't recall exactly when it is used, but it definitely is. You're right in that it doesn't make sense, unless you were trying to guarantee that "objects are ordered consistently but arbitrarily (so that sorting a heterogeneous array yields a consistent result)", which, as the docs point out, python does.
CB
@Olivier, it just happens to work that way for you: try 999.01 instead of 0.1 and you'll see exactly the same results, showing you it **doesn't** "work fine" (it's a stopped clock: correct twice a day;-). The _types_ end up getting compared (and these type comparisons need not work the same way in different Python installations), not the _values_ as one would normally expect.
Alex Martelli
@CB, `id` is used as the last resort for _non-ordering_ comparisons (equality and inequality) and hashing, where it makes perfect sense; it's never used for _ordering_ comparisons such as `<`. Instead, heterogeneous ordering comparisons end up comparing the _types_ instead of the value.
Alex Martelli
@Alex - ah, thanks. I wasn't sure exactly when it was used.
CB
I see. Very interesting discussion. I had pretty much missed the point of the question, sorry. +1 to both of you!
Olivier
+4  A: 

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.

Alex Martelli
Ah, I didn't know about the cross type sorting on the type object. Thanks for your clear explanation.
CB
@Alex: Well, after much hand wringing and beard pulling, the rules have been relaxed a bit in Python 2.7: Decimal and float instances now compare sensibly with each other. The main technical issue was preserving the rule that numbers that compare equal should also hash equal. (Don't try comparing Decimal and Fraction instances, though!)
Mark Dickinson