[Python-Dev] Python's C interface for types (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Thu Feb 1 21:02:48 CET 2007

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

More information about the Python-Dev mailing list