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.

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

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