Home Original page

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

Alex Martelli aleax at aleax.it
Fri Nov 22 10:18:11 EST 2002 
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
More information about the Python-list mailing list