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

[Alex Martelli]

Andrew Koenig wrote:

> Eric> So I told myself: wouldn't it be great if max(None, x) or
> Eric> min(None, x) always simply returned x?
> 
> My first thought was that this was an excellent idea.
> 
> Then I thought again.
> 
> Here's the problem:  The notion that max(None, x) and min(None, x)
> should both return x is one of three desirable properties that cannot
> all be true at once.  Here are the other two:
> 
>         1) Whenever x < y, min(x, y) is x and max(x, y) is y.
> 
>         2) < is an order relation over all types.

Unfortunately point (2) doesn't hold in Python today.


> The desirability of (1) should be obvious.  (2) is more subtle, but
> it is necessary for it to be possible to sort a vector of heterogenously
> typed objects.

Indeed, you can sort a list containing, say, a None, a string, an
integer and a float -- but if you add to the list a fifth element
that is a complex, POOF, you can't sort it any more.  That didn't
use to be so, if I recall correctly, in Python 1.5.2, but has
been that way for quite a while now.  Why comparing string 'plak'
with the number 23 is OK, but comparing it with 23j isn't, kind
of escapes me -- but apparently property (2) was deemed less
desirable than the ability to forbid e.g. comparing 23j with 42j.
To the point of changing Python's previous behavior, no less:-(.


> Now, if max(None, x) and min(None, x) both yield x, and (1) is true,
> then x > None and x < None must both be true.  But then (2) cannot
> be true.
> 
> So the cost of your proposal would be either to break the consistency
> between max/min and >/<, or to render unsortable vectors of values
> that include None.
> 
> I don't think it's worth it.

I don't think it's worth it either -- even the weaker guarantee of
being able to state (just to play with chaining...;-):
    b >= min(a,b) <= a and b <= max(a,b) >= a
*unless an exception is raised while evaluating the expression* is
still pretty good.

However, _some_ kind of language-mandated guarantees about the
behavior of certain cross-type comparisons _might_ be nice.  Right
now, I don't think the language makes ANY such guarantees (except
for comparisons between ints, longs and floats, and between plain and 
Unicode strings, where sensible conversions are indeed guaranteed).


Alex