[Python-Dev] Python's C interface for types

[Jim Jewett]

Nick Maclaren wrote:
>>> I really do mean that quite a lot of floating-point bells and whistles
>>> are non-transitive.

Martin v. Löwis wrote:
>> If so, they just shouldn't use the equal operator (==). == ought to
>> be transitive. It should be consistent with has().

Nick Maclaren wrote:
> Fine.  A very valid viewpoint.  Would you like to explain that to
> the IEEE 754 people?

When Decimal was being argued, Tim pointed out that the standard
requires certain operations, but doesn't require specific spelling
shortcuts.  If you managed to do (and document) it right, people would
be grateful for methods like

    a.exactly(b)
    a.close_enough(b)
    a.same_expected_value(b)

but that doesn't mean any of them should be used when testing a==b

(In Lisp, you typically can specify which equality predicate a
hashtable should use on pairs of keys; in python, you only specify
which it should use on objects of your class, and if the other object
in the comparison disagrees, you're out of luck.)

> Strictly, it is only the reflexive property that IEEE 754 and the
> Decimal module lack.  Yes, A == A is False, if A is a NaN.

Therefore NaNs should never be used (in python) as dictionary keys.
Therefore, they should be unhashable.

Also note that PyObject_RichCompareBool (from Objects/object.c)
assumes the reflexive property, and if you try to violate it, you will
get occasional surprises.

> We already have the situation where A == B == 0, but where
> 'C op A' != 'C op B' != 'C op 0'.  Both where op is a built-in
> operator and where 'C op' is a standard library function.

That's fine; it just means that numeric equality may not be the
strongest possible equivalence.  hash in particular just happens to be
defined in terms of ==, however == is determined.

-jJ