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

[Nick Maclaren]

"Jim Jewett" <jimjjewett at gmail.com> 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

Hmm.  That is misleading, as you state it.  IEEE 754R doesn't include
specific spellings, but IEEE 754 assuredly does.  For example, it
states that the equality operator that delivers False for NaN = NaN
is spelled .EQ. in Fortran.

There was no C standard at the time, but the "ad hoc' spellings are
clearly intended for C-like languages, and C99 is very clear that
the above equality operator is spelled '=='.

However, there is no requirement that Python uses those names.  What
IS important is (a) that the comparisons are consistent, (b) that
IEEE 754 (and IEEE 754R) define no reflexivity-preserving equality
operator and (c) that the current float type derives its comparisons
from C.

> (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.)

Yup.

> > 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.

Again, a very valid point.  Are you suggesting a change? :-)

Currently, on my Linux system, Decimal raises an exception when trying
to hash a NaN value but float doesn't.  Is that a bug?

> 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.

Oh, yes, indeed!

> > 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.

NO!!!  What it means is that the equality operator may not be the
strongest numeric equivalence!  A much stronger statement.

As I said, I am not grinding an axe, and have no answers.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679