> [Guido] > > Hm. cmp is a *builtin function*. That seems an exceedingly odd place > > to stick arbitrary constants -- much more so than type objects (like > > Martin's recently proposed unicode property for controlling error > > handling). > > If the high/low (or hi/lo, Max/Min, etc.) objects themselves are > subclasses of object, it may make sense to just place them at > object.high/object.low. Why two subclasses? Shouldn't one with two instances suffice? > One idea was to create a type called 'extreme', bind it to cmp.extreme, > and subclass high/low from extreme. Of course that is just one more > arbitrary object attached to cmp, which is even more odd. > > Another option would be for min.Min and max.Max, but I'm pretty sure > that would be confusing. > > The convenient part about putting them as attributes of cmp is that it > is obvious that they are most useful when it comes to comparing against > other objects. I'm not convinced. --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