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

[Alexander Schmolck]

Andrew Koenig <ark at research.att.com> writes:

> 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.
> 
> 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.
> 
> 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.

propably not, but then it's already broken anyway, since apparently abusing
comparison operators to do something completely different was deemed better
than introducing new (or user-defined) operators.


>>> from Numeric import array
>>> a = arange(3)
>>> if a > 1 and 1 > a: print "surprise!"
...
surprise!


alex