[Python-Dev] Re: Python-checkins digest, Vol 1 #370 - 8 msgs
Guido van Rossum
guido@python.org
Mon, 28 Feb 2000 13:54:34 -0500
> On Mon, 28 Feb 2000, Guido van Rossum wrote:
> >
> > This is different. Maybe the docs are wrong; I always intended for
> > both max(a, b, ...) and max(seq) to be valid.
(BTW, I was wrong about the docs. The docs explain quite clearly
that max(a) is different from max(a, b, ...). Learning Python and
Python Essential Reference also document both forms.)
> I suppose in this case it's clear what you mean just from the
> number of arguments. But there is a potential surprise if someone
> who expects to have to say max(a, b, ...) then writes
>
> apply(max, tuple)
>
> and tuple turns out to only have one element. (I don't think
> i've ever realized that we could use min() or max() on a sequence.)
Yes, but there simply isn't any need to do this, so it won't occur in
practice.
> > (BTW, perhaps the __contains__ changes should be extended to __max__
> > and __min__? They share many of the same issues.)
>
> Indeed -- but then who do you trust? The first element of the
> sequence? Is it acceptable for
>
> max(a, b, c, d)
>
> to read as
>
> "a, please tell me which is the maximum among yourself, b, c, and d"
>
> ? Does 'a' then have to take care of the type-comparison logic
> for consistency with everything else? What if 'a' happens to be
> a built-in type but 'c' is a user-defined instance?
No, that's not what I meant. __min__ and __max__ would be methods of
sequences. The min() and max() functions would catch the special case
of multiple arguments and translate to min((a, b, ...)) etc. before
looking for __min__.
--Guido van Rossum (home page: http://www.python.org/~guido/)