Issue 807771: Max and min are incorrect with one argument (original) (raw)

Issue807771

Created on 2003-09-17 11:49 by gpk, last changed 2022-04-10 16:11 by admin. This issue is now closed.

Messages (3)
msg18174 - (view)	Author: Greg Kochanski (gpk)	Date: 2003-09-17 11:49
max(1) raises 'TypeError: iteration over non-sequence', when it should simply return 1 Min has the same problem. If there is one person in a room, and you ask for the tallest person, there is a well-defined answer. The tallest person is the only person. So is the shortest person. I ran across this when I was doing apply(max, list) / apply(min, list) to find out the ratio of maximum to minimum entries in a list. With a single-element list, I expected it to return 1, instead of raising an exception.
msg18175 - (view)	Author: Raymond Hettinger (rhettinger) *	Date: 2003-09-22 19:24
Logged In: YES user_id=80475 That behavior is consequence of interpreting a single argument as an input sequence while interpreting multiple arguments as the sequence itself. Given a single argument, Python could make some reasonable guesses: max(3) --> 3 and max((3,4)) --> 4, but guessing is not the Pythonic way. Also, I think max(x) tends to be an error condition when x is not iterable, so it would be unwise to simply return x and let the error pass silently. If it makes you feels better, you *are* the tallest, smartest, and richest OP for this bug report ;-)
msg18176 - (view)	Author: Terry J. Reedy (terry.reedy) *	Date: 2003-09-29 00:47
Logged In: YES user_id=593130 I think the gimmick of having a function of 1-m arguments treat one arg as a sequence is a design bug that asks for problems. With the addition of *seq, it is even more unnecessary. But for backwards compatibility, it must remain until 3.0. Greg: you faked yourself out by using apply. Go with the flow and just use max(list)/min(list): >>> max([2])/min([2]) 1