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

[Guido van Rossum]

Finding more realistic use cases is key -- the actual spec is pretty
obvious and doesn't worry me in terms of added language or implementation
complexity.

I think just finding a data structure that should implement its own min/max
funtionality (or maybe one of these, like heapq) is not enough motivation.
You have to find code where such a data structure (let's say a Tree) is
passed to some function that also accepts, say, a list. Then that function
would benefit from being able to call just `min(x)` rather than `x.min() if
isinstance(x, Tree) else min(x)`. If whenever you have a Tree you know that
you have a Tree (because it has other unique methods) then there's no
burden for the user to call x.min().

--Guido

On Wed, Jun 20, 2018 at 5:24 AM James Edwards <jheiv at jheiv.com> wrote:

> >  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/
>>
>
> _______________________________________________
> 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/
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180620/4fe46fc3/attachment.html>