[Python-Dev] Comparison speed (original) (raw)

Guido van Rossum guido@digicool.com
Tue, 15 May 2001 10:27:31 -0500

[Martin v. Loewis] > Is this really exactly what Python would guarantee? I'm surprised that > x==x would always be true, but x!=x might be true also. In a type where > x!=x holds, wouldn't people also want to say that x==x might fail? IOW, > I had expected that you'd reduced it to > > if (v == w && op == PyEQ) /* then return PyTrue */ > if (v == w && op == PyNE) /* then return PyFalse */

[Tim]

I agree that would be more analogous to what PyObjectCompare() does.

I'm not sure either make sense for rich comparisons; for example, under IEEE-754 rules, a NaN must compare not-equal to everything, including itself(!), and richcmps are the only hope Python users have of modeling that. Doing those pointer checks before giving richcmps a chance would kill that hope. Can we agree to drop this one until somebody produces stats saying it's important? I have no reason to suspect that it is.

PEP 207 is quite explicit that == and != are not to be assumed each other's complement. It is silent on the x==x issue but the PEP mentions IEEE 754 so I agree that this also shouldn't be cut short.

--Guido van Rossum (home page: http://www.python.org/~guido/)