> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4