[Python-Dev] Behaviour of max() and min() with equal keys

[Jeffrey Yasskin]

On Tue, Sep 7, 2010 at 1:44 PM, Mark Dickinson <dickinsm at gmail.com> wrote:
> On Tue, Sep 7, 2010 at 8:34 PM, Matthew Woodcraft
> <matthew at woodcraft.me.uk> wrote:
>> In CPython, the builtin max() and min() have the property that if there
>> are items with equal keys, the first item is returned. From a quick look
>> at their source, I think this is true for Jython and IronPython too.
>
> It's actually not clear to me that this behaviour is ideal;  it might
> make more sense to have max() return the first item among equal
> largest elements, and min() return the last item.  That way, the
> special case of two operands has the nice property that (max(x, y),
> min(x, y)) is always either (x, y) or (y, x), rather than being
> possibly (x, x) or (y, y).  (That is, id(max(x, y)) and id(min(x, y))
> are id(x) and id(y) in one order or the other.)
>
> The max and min methods for the Decimal module take care to work this
> way, for example:
>
>>>> x, y = Decimal(2), Decimal('2.0')
>>>> x.max(y), x.min(y)
> (Decimal('2'), Decimal('2.0'))
>
> But:
>
>>>> max(x, y), min(x, y)
> (Decimal('2'), Decimal('2'))
>

Decimal may actually have this backwards. The idea would be that
min(*lst) == sorted(lst)[0], and max(*lst) == sorted(lst)[-1]. Given a
stable sort, then, max of equivalent elements would return the last
element, and min the first. According to Alex Stepanov, this helps
some with composing these small order statistics into larger
stably-ordered functions.

I do think Decimal.max's answer is better than the builtin's answer,
and that the incremental benefit from returning the last instead of
first is pretty small.