> [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 == Py_EQ) /* then return Py_True */ > > if (v == w && op == Py_NE) /* then return Py_False */ [Tim] > I agree that would be more analogous to what PyObject_Compare() 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4