>> Moreover, for some data structures, the __cmp__ approach can be >> expensive. For example, if you're comparing sequences of any kind, >> and you know that the comparison is for == or !=, you have your answer >> immediately if the sequences differ in length. If you don't know >> what's being tested, as you wouldn't inside __cmp__, you may spend a >> lot more time to obtain a result that will be thrown away. Guido> Yes. OTOH, as long as cmp() is in the language, these same situations Guido> are more efficiently done by a __cmp__ implementation than by calling Guido> __lt__ and then __eq__ or similar (it's hard to decide which order is Guido> best). So cmp() should be removed at the same time as __cmp__. Yes. Guido> And then we should also change list.sort(), as Tim points out. Maybe Guido> we can start introducing this earlier by using keyword arguments: Guido> list.sort(lt=function) sorts using a < implementation Guido> list.sort(cmp=function) sorts using a __cmp__ implementation The keyword argument might not be necessary: It is always possible for a function such as sort to figure out whether a comparison function is 2-way or 3-way (assuming it matters) by doing only one extra comparison.
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