Steven D'Aprano added the comment:
Even though I agree with closing this issue, there is some support for ignoring
certain "missing values" when calculating min() and max(). The draft 2008
revision of IEEE-754 includes two functions maxNum and minNum which silently
skip over NANs:
https://en.
R. David Murray added the comment:
Just select your initial value as something that works with the sequence you
are iterating. If necessary, you can define custom 'always maximum' and
'always minimum' objects. (You could try proposing builtin objects with that
feature on the python-ideas mai
Simeon Visser added the comment:
So, to clarify, as the problem no longer occurs in Python 3 (as it requires the
caller to provide only orderable objects) I'm not sure a meaningful change can
be made here. It would require changing the behaviour of min/max in Python
2.7.x in a way that could b
Simeon Visser added the comment:
This doesn't happen in Python 3 as None can't be compared to other elements:
>>> min([1,2,3,None])
Traceback (most recent call last):
File "", line 1, in
TypeError: unorderable types: NoneType() < int()
I can also imagine people now using min with the intende
New submission from Maytag Metalark:
`None` should never be the result of the built-in `min` and `max` functions.
When `None` is supplied as one of the values to check, it should never be
chosen as the result.
This would make it much easier to find a minimum and/or maximum while iterating
ove
