[Python-ideas] "Exposing" `__min__` and `__max__`

[Franklin? Lee]

On Wed, Jun 27, 2018 at 11:30 AM, Michael Selik <mike at selik.org> wrote:
> On Wed, Jun 27, 2018 at 8:16 AM Franklin? Lee
> <leewangzhong+python at gmail.com> wrote:
>>
>> On Wed, Jun 27, 2018, 10:31 Steven D'Aprano <steve at pearwood.info> wrote:
>>>
>>> On Wed, Jun 27, 2018 at 06:52:14AM -0700, Michael Selik wrote:
>>> > My intent was to ask where a range was in fact passed into max, not
>>> > merely
>>> > where it could be. It'd be enlightening to see a complete, realistic
>>> > example.
>>>
>>> A complete, realistic example is as I said: you call max() on some
>>> object which you don't control, the caller does. You could be
>>> passed a list, or a set, or a bitset, a binary search tree, a range
>>> object, whatever the caller happens to pass to you.
>>
>>
>> Let's just assume Michael wants to know, and isn't making an argument
>> against the proposal.
>
>
> I do want to know, but it's also an argument against the proposal -- that no
> one has contributed in-context usage to demonstrate the value. I'd want to
> see code that currently uses ``if isinstance`` to switch between ``max(x)``
> and ``x.max()``. Chris Barker explained the issue well.

Then maybe you shouldn't have picked on the verbatim case of `len(range(...))`.

You won't find many examples deciding between `max(x)` and `x.max()`.
`np.nanmax(x)` will optimize the case where you care about efficiency.
(By the way, Numpy checks for `x.max` if `x` isn't an `ndarray`, so it
already kind of implements the proposal.)

I honestly can't imagine a case where you need to know the max of some
possibly-unsorted collection, but don't eventually iterate through the
whole thing anyway (no difference in asymptotic time). You might have
some savings sometimes, but the overall gain is unpredictable, and
shouldn't be depended on.

A case more realistic to me is when you know it's definitely a
collection that knows its max/min, but you don't know what kind of
collection it is. But a sorted collection is pretty much a sequence,
and you can usually get the first or last element using c[0] and
c[-1], unless it's a SortedDict. A heap or a Young tableau knows its
min, and only has to search its leaves/boundary for its max (or vice
versa).

For a sorted collection, you may want to check against min and max
before inserting, deleting, or searching for an element. However,
these checks can be implemented by the functions doing the
insert/delete/search.

I expect existing uses for dunder max will appear in generic algorithm
libraries, rather than in concrete uses. If you're switching to a
sorted collection, it suggests that you want efficiency, and I imagine
you'll modify your code to fit the new data structure.