On Wed, Jun 27, 2018 at 06:52:14AM -0700, Michael Selik wrote:
> > > Have you ever written ``max(range(x))`` in production code?
> >
> > I have never written that.
> >
> > But I have written ``max(iterable)`` dozens of times, where iterable
> > could be a range object.
> >
>
> 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.
If you control your own input, then this doesn't sound too interesting.
You know when you will get a list, and you can call max() on it, and you
know when you are passing yourself a tree, and you can give your own
tree a max() method and call that.
But if you don't control your input, then this is a good way to delegate
back to the unknown object of an unknown class which knows itself.
Currently max() and min() have no choice but to walk the entire data
structure, even if the object already knows its own maximum and minimum
values. That's wasteful.
An analogy: in Ruby, the equivalent of the len() built-in falls back on
iteration as a last resort for any object which doesn't define a len
method:
size = 0
for x in obj:
size += 1
return size
By this analogy, max() and min() currently are like that last-resort
version of len(), except they do it for *every* object that can be
iterated over even when there's no need.
Imagine that Python's len() always walked the entire iterable, from
start to end, to count the length. Now suppose that you proposed
adding a __len__ protocol so that objects that know their own length
can report it quickly, and in response I argued that
len(range(x))
was unrealistic and that there is no need for a __len__ method
because we could just say
range(x).stop
instead. I don't think you would find that argument very persuasive,
would you?
--
Steve
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
