On Mon, 5 Jan 2004, Raymond Hettinger wrote: > +1 It would occasionally be useful to have ready access to an object > whose sole purpose is to compare higher or lower than everything else. > > Robert Brewer's idea to use spelled-out names, cmp.high and cmp.low, is > easy to remember, better for non-native English speakers, and reasonably > compact. What about cmp.Max and cmp.Min? Non-native English speakers already have to know max() and min() and what they do, this might be easier to understand. However, it might make things a little more confusing for native English speakers. As for use cases, this stuff often comes up in the multitude of spatial data structures used for range searching. Segment trees, R-trees, k-d trees, database keys, etc. would all make use of this. The issue is that a range can be open on one side and does not always have an initialized case. The solutions I have seen are to either overload None as the extremum or use an arbitrary large magnitude number. Overloading None means that the builtins can't really be used without special case checks to work around the undefined (or "wrongly defined") ordering of None. These checks tend to swamp the nice performance of builtins like max() and min(). Choosing a large magnitude number throws away the ability of Python to cope with arbitrarily large integers and introduces a potential source of overrun/underrun bugs. -a
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