> > > 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. > > Seemingly you are not convinced that creating attributes for cmp is > reasonable. Seemingly, attributes for min and max are equivalently as > unreasonable (and may be confusing). > > How about them being attributes of object, or even placed in the math > module? > > - Josiah Module attributes make sense; make them attributes of object has the unfortunate side effect that they will be attributes of *all* objects and that doesn't seem a good idea. The math module is only appropriate if this is primarily about float numbers. And see PEP 747 in that case. --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