[Python-ideas] 'default' keyword argument for max(), min()

George Sakkis george.sakkis at gmail.com
Thu Apr 16 22:14:10 CEST 2009

On Thu, Apr 16, 2009 at 2:57 PM, Raymond Hettinger <python at rcn.com> wrote:

> So the motivating case for a default argument boils down to:
> * The input is an iterable (otherwise the number of positional arguments is
> already known when the call is written).


> * The input is not a sequence of known length (otherwise, you could just use
> "min(seq) if seq else default").

True, but the latter is easy to forget, less succinct and easy to miss
when refactoring a function to work on iterables instead of sequences

> * The input is potentially long (otherwise you could trivially convert to a
> sequence with list(iterable)).

That should be the default mentality; unless one *knows* that the
input is "short" (for some definition of "short"), he should assume
that it is potentially long. Regardless of the length, I don't think
it's the responsibility of the iterable's consumer to convert it; if
the input is always short, why it's not a sequence in the first place

> * The input is potentially empty (otherwise you wouldn't need a default).


> * There is a semantically meaningful default case for an empty input.

Yes, typically 0 or None.

> * You only want the min or max but no other information from the iterable
> (otherwise you would need to convert it to a sequence so that min/max
> wouldn't consume all the data).

Yes, I often use min/max with gen. expressions: Compare:
     if min(f(x) for x in iterable if x>0) > 0:
   _values = [f(x) for x in iterable if x>0]
   if _values and min(_values) > 0:

> I think this is a YAGNI case.  Yes, it does come up every now and then
> but I don't think it is worth complicating what should be a very simple
> function.

The discussion has indeed sidetracked with handling the special cases,
signature definition and whatnot, but I believe meeting the conditions
you outlined above is not as rare as their number implies. I hope the
rest of the thread focuses on this motivating case so that this
proposal is not rejected due to excessive bikeshedding.


More information about the Python-ideas mailing list