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

[James Edwards]

>  Are there any builtins or std library classes that offer their own
min()/max() methods?

My first instinct was heapq[1], since the way to access the min value is
simply heap[0] (and I thought it could benefit from __min__) -- it's almost
the perfect motivating example.  But as it stands, the module uses
functions to operate directly on a standard list, so even if __min__ were
exposed, min(heap) would still iterate over the entire list.

That being said, a heap *class* could take advantage of this, and provide a
semantically consistent optimization.

I'm not sure how many examples will be found in stdlib, as I expect this
optimization to be restricted to specialized container types like heaps,
but I'll keep searching.

[1] https://docs.python.org/3.6/library/heapq.html

On Wed, Jun 20, 2018 at 3:00 AM, Steven D'Aprano <steve at pearwood.info>
wrote:

> On Wed, Jun 20, 2018 at 07:05:19AM +0300, Serhiy Storchaka wrote:
> > 19.06.18 22:18, James Edwards пише:
> > >I've only recently looked for these special methods, so that in and of
> > >itself may be the reason these methods aren't exposed, but I could
> think
> > >of objects that may wish to implement __min__ and __max__ themselves,
> > >for efficiency.
> >
> > There are two questions.
> >
> > 1. What to do with additional min() and max() arguments: key and default.
>
> Since there are no reflected versions of min/max, there is no trouble
> with extra arguments. Just pass them through to the dunder:
>
> min(obj, key=x, default=y) => type(obj).__min__(key=x, default=y)
>
>
> > 2. Is the need of this feature large enough? Will the benefit for
> > special cases exceed the drawback of increasing implementation
> > complexity and slowing down common cases?
>
> Reasonable questions, but I don't think that the cost of testing:
>
>     if hasattr(type(obj), '__min__')
>     # or equivalent
>
> is going to be very large. Amortized over O(N) comparisons, that's
> practically free :-)
>
> More important, I think, is the increase in API complexity. That's two
> more dunders to learn about.
>
> The first part is critical: is this useful enough to justify two more
> dunders? I think the answer is a definite Maybe. Or perhaps Maybe Not.
>
> I think that without at least one use-case in the standard library,
> perhaps we should hold off on this. Unless numpy arrays are important
> enough to justify this on their own?
>
> Are there any builtins or std library classes that offer their own
> min()/max() methods? If so, that would be good evidence that making this
> a dunder-based protocol has stdlib use-cases.
>
>
>
> --
> Steve
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180620/b30ef770/attachment.html>