Proposal: min(None, x) and max(None, x) return x

[Erik Max Francis]

Eric Brunel wrote:

> So I told myself: wouldn't it be great if max(None, x) or min(None, x)
> always simply returned x?

The problem here is that you can already do comparisons between
heterogeneous types (so long as one of them isn't a complex number, that
is).  You're guaranteed that comparison between different types will
return some consistent ordering, but you're not guaranteed what that
ordering will be and you're not guaranteed that it could change from
version to version or implementation to implementation.

None is just another instance of a type, as far as this is concerned, so
in a given version of your interpreter, None will either be less than
all integers or greater than all integers; which it will be may depend
on the version and the variant (e.g., Python, Jython, Stackless, or some
future implementation).

The min and max builtins just test for this ordering, so None has no
special significant in this context.  If you mix a None in with, say,
integers in a call to min or max, either it will always be the min and
never the max, or it will always be the max and never the min (again,
which one is an implementation detail).  Special-casing the existence of
None in a call to min/max seems like an expectation violation to me.

Instead what I would recommend is creating a custom class and overriding
__cmp__ so that it always tests either greater or less than everything
else, and using an instance of _that_ object as your sentinel in your
calls to min and/or max (obviously, you'll have to choose the
appropriate sentinel for min or max).

-- 
 Erik Max Francis / max at alcyone.com / http://www.alcyone.com/max/
 __ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/  \ The little I know, I owe to my ignorance.
\__/ Sacha Guitry
    Bosskey.net: Counter-Strike / http://www.bosskey.net/cs/
 A personal guide to Counter-Strike.