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