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

["Martin v. Löwis"]

Nick Maclaren schrieb:
>> If so, they just shouldn't use the equal operator (==). == ought to
>> be transitive. It should be consistent with has().
> 
> Fine.  A very valid viewpoint.  Would you like to explain that to
> the IEEE 754 people?

Why should I? I don't talk about IEEE 754, I talk about Python.

> 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.  But
> the definition of 'transitive' often requires 'reflexive'.

I deliberately stated 'transitive', not 'reflexive'. The standard
definition of 'transitive' is "if a==b and b==c then a==c".

> The most common form was where comparison was equivalent to subtraction,
> and there were numbers such that A-B == 0, B-C == 0 but A-C != 0.  That
> could occur even for integers on some systems.  I don't THINK that the
> Decimal specification has reintroduced this, but am not quite sure.

I'm not talking about subtraction, either. I'm talking about == and
hash.

> Fine.  Again, a very valid viewpoint.  Would you like to explain it
> to the IEEE 754, Decimal and C99 people, and the Python people who
> think that tracking C is a good idea?

I'm not explaining anything. I'm stating an opinion.

> This one is NOT going to go away, and is going to get more serious,
> especially if extended floating-point formats like Decimal take off.
> Note that it is not a fault in Decimal, but a feature of almost all
> extended floating-points.  As I said, I have no answer to it.

It doesn't look like you *need* to give an answer now. I thought
you were proposing some change to Python (although I'm uncertain
what that change could have been). If you are merely explaining
things (to whom?), just keep going.

Regards,
Martin