[Python-ideas] "Exposing" `__min__` and `__max__`
Guido van Rossum
guido at python.org
Wed Jun 20 11:24:21 EDT 2018
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
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().
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, since the way to access the min value is
> simply heap (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.
>  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>
>> 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
>> > >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
>> 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.
>> Python-ideas mailing list
>> Python-ideas at python.org
>> Code of Conduct: http://python.org/psf/codeofconduct/
> Python-ideas mailing list
> Python-ideas at python.org
> Code of Conduct: http://python.org/psf/codeofconduct/
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas