Guido> I realized the first sentence wasn't very clear. I meant that Guido> implementing cmp() is inefficient without __cmp__ for some types Guido> (especially container types). Example: Guido> cmp(range(1000)+[1], range(1000)+[0]) Guido> If the list type implements __cmp__, each of the pairs of items Guido> is compared once. OTOH, if the list type only implemented Guido> __lt__, __eq__ and __gt__, cmp() presumably would have to try Guido> one of those first, and then another one. If it picked __lt__ Guido> followed by __eq__, it would get two False results in a row, Guido> meaning it could return 1 (cmp() doesn't really expect Guido> incomparable results :-), but at the cost of comparing each Guido> pair of items twice. If cmp() picked another set of two Guido> operators to try, I'd simply adjust the example. Yes. If you want to present a 3-way comparison to users, an underlying 3-way comparison is the fastest way to do it. The trouble is that a 3-way comparison is definitely not the fastest way to present a 2-way comparison to users. So if you want users to see separate 2-way and 3-way comparisons, I think the fastest way to implement them is not to try to force commonality where none exists.
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