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 <[email protected]> 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 <[email protected]> > 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 >> [email protected] >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > _______________________________________________ > Python-ideas mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
