Re: [Python-Dev] Re: PEP 326 now online
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/)
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.
You mean PEP 754, right? Just like creating an arbitrarily large integer, floating point infinity is also arbitrary, and may not be big enough. I just got a comment from another user suggesting modifying the min/max.__cmp__ so that they are the actual minimum and maximum. An interesting approach, which makes some sense to me. - Josiah P.S. Right now:
min > max 1
participants (2)
-
Guido van Rossum -
Josiah Carlson