> I'd still be in favour of giving strings a richcompare, since it > allows to optimize what I think is the single most frequent case: > Py_EQ on strings. I have always thought that eventually (but long before Py3K!) all objects would only support rich comparisons and the __cmp__ and tp_compare slots would become completely obsolete. I realize I probably haven't expressed this thought clearly, and I'm not going to push for this to happen quickly or forecefully, but it's nevertheless how I see things. I expect it would allow a tremendous cleanup of the comparison code. It will never reach the simplicity of cmp() -- but think of Einstein's (?) rule "things should be as simple as they can be, but no simpler." Clearly cmp() was too simple. :-) Anyway, it worries me whenever I hear someone express the thought that adding rich comparisons to a particular object type would be a bad idea because it would slow things down. --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