[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/)