Lots of times I want to find the largest element of a list or sequence,
defaulting to 0 if the list or sequence is empty. max(seq) throws an
exception if seq is empty, so I end up using reduce(max, seq, 0). That
is a standard functional programming idiom but can be a bit confusing to
imperative-style Python programmers.

max with multiple args is already overloaded to mean the maximum of the
args, so I think it would be a good fix to add a keyword arg to accept
an optional initial value: max(seq, start=0). For symmetry, min should
accept the same arg.

The alternatives to using reduce aren't so attractive. If seq happens
to be a list, there might be a temptation to conditionalize on
len(seq)==0, but that is poor style since it will break if seq later
changes to an arbitrary sequence. And trying to test it by calling
.next() and saving the value and/or trapping StopIteration gets awfully
messy.

In case you don't remember it, this thread from python-ideas is relevant:

http://mail.python.org/pipermail/python-ideas/2009-April/004107.html

I can't tell from rereading the thread whether the support was for the
'initial' version, or the 'default' version that was more-or-less
rejected as being too confusing. If the support was for the initial
version then that would be support for this proposal.

David, I'm not on that mailing list so hadn't seen the earlier
discussion. I sympathasize with Raymond's YAGNI argument because I'm
comfortable with reduce(max,seq,0); but then I remember there was once a
movement to remove the "reduce" function from builtins, which would have
broken that idiom. I also understand that not everyone is comfortable
with that style. I recently had to hand over some code to another
programmer where I had used that idiom, and in the course of adding
comments to the code in preparation for the handover, I found myself
writing quite a few words about why I'd used "reduce" that way, so I
figured that "explicit is better than implicit" suggests adding default
or initial args to the max function, just like "reduce" already has (I
figure that max on a sequence is a special case of reduce).

My proposed python implementation:

def mymax(*args, **kwargs):
  if len(args) > 1: return max(*args)
  if len(args) == 0: raise TypeError, "mymax needs at least one
positional arg"
  if 'initial' in kwargs: return reduce(max,args[0],kwargs['initial'])
  return reduce(max,args[0])

Sorry, that "in case you don't remember' was directed at Raymond, not you.

Since Raymond took ownership of this issue I don't think he's dismissing
it (at least not yet :) I think his YAGNI was for the 'default'
version, which is not what you are proposing.

Note that 'reduce' is _not_ a builtin in Python3, although it is still
available and so the idiom is not broken, just slightly wordier.

Here’s a summary of my research so far (including discussion with other
programmers, a Google code search, discussion on #python-dev on IRC, and
comparing the proposal to other APIs with start-arguments such as sum(),
reduce(), and enumerate()):

1. Showed several examples to other programmers and found that they did
   not immediately get what the start argument was trying to do. Was a
   start argument the same as:

 reduce(max, seq, 0)     # zero when empty and never less than zero
 max(seq) if seq else 0  # zero when empty (only works for sequences)
 max(chain([0], seq)     # zero when empty and never less than zero

2. There is an issue of API complexity. Even if a feature is useful and
   clear, it may not be a good idea when the API of a function is already
   complex. In the case of min()/max(), we already have special handling
   for one argument (treated as an iterator) versus no arguments (treated
   an error versus multiple arguments (treated as an input sequence of
   values). We also have a key= argument. Taken together, the min/max
   functions already have a lot of features.

3.Beyond the complexity of having too many features in a function that
should be simple, there is also an issue of how those features would
interact:

 min(iterable, key=f, start=x)  # is the default value x or f(x)?
 min(start=x)          # should this be allowed?
 min(*args, start=x)   # if so, what is behavior when len(args)==0 or 1
or 2?

4. The argument about reduce(max, seq, 0) being confusing to
   non-functional programmers isn’t persuasive since perfectly clear
   (though multi-line) exception-catching or size-checking imperative forms
   can be written, or one can can simply factor-out any recurring
   expressions if they seem awkward or confusing:

    def max_or_zero(iterable):
        'Return zero if the iterable is empty or max(0, max(iterable))
otherwise'
        return functools.reduce(max, iterable, 0)

5. In the case of sequences, it can be clearer to write:

max(seq) if seq else 0
max(seq + [0]) # or use itertools.chain()

6. A code search showed that max() is mostly used in a two-argument
   form. When it does get used with iterables, it doesn't seem common to
   trap ValueErrors.

1. Yes, the idea is to figure out the best solution and go with it (or
   decide to do nothing). That many possibilities exist just points to the
   need for experience and wisdom in identifying the best choice ("one and
   preferably only one"). One of the attractive points about Python is it
   comes with so many such decisions already wisely made. The design
   wisdom embodied in Python is almost like a useful software library in
   its own right. So the presence of multiple choices should be seen as an
   invitation to resolve the issue, not a flag to keep it unresolved.

2. I agree that the multi-arg and iterator API's should have been done
   as separate functions (or denoted through a keyword arg), but what we
   have isn't too bad, and it's what we have.

3. min(iterable, key=f, start=x) should obviously default to the same
   thing as min([x], key=f). min(*args, start=x) should only be allowed
   when len(args)==1, since the start arg is restricted to the case of
   minimum over an iterator. min(start=x) should not be allowed.

4. I'm in general unpersuaded by the argument that a stdlib function
   isn't worth having because the same thing can be done by bloating up the
   user code. Python code should be concise, which means using the stdlib
   in preference to writing more user-defined functions that the next
   maintainer has to figure out, and which may have their own bugs and
   unhandled edge cases. For stdlib design, it's mostly a matter of
   deciding whether a construction occurs often enough to write a re-usable
   function for. In this case it wouldn't have occurred to me to write any
   of those suggested versions, instead of writing reduce(max, iterator, 0)
   with an explanatory comment. But even the observation that "reduce"
   made me bloat up the comments in the code, rather than the code itself,
   was enough to get me to suggest adding the initial arg.

5. I don't think it's good to rely on bool(seq) or len(seq) to be
   available if there's a simple construction (like here) that works for
   arbitrary iterables. It's better to handle the general case. I hadn't
   even realized til just now that "sequence" and "iterable" didn't mean
   the same thing.

6. Yes, I know it's not common to trap ValueErrors when using max with
   iterables. I wrote code without such traps myself and then got bitten
   by unhandled exceptions when some of those iterables turned out to be
   empty (hence my "reduce" hack). It wouldn't surprise me if lots more
   such code out there is similarly buggy. I think it's good to make
   bug-avoiding mechanisms obvious and convenient.

Thanks for the thoughtful reply. To give the idea another chance,
today, I showed a code example to another experienced programmer.

"What does this function return?
max([-2, 5], start=0)
"

The person had a hard time making any sense of it. Perhaps the start
argument was an index, or starting position, or a ceiling, or a floor.

I'm rejecting the feature request for several reasons:

• the code sample doesn't have obvious meaning to experienced programmers

• the API of the min/max functions is already too complex -- the
  language needs to be easy to learn and remember

• the start keyword argument doesn't interact well with the other
  features (such as the key argument or positional arguments). Mark
  questioned whether the key function would apply to the start value (any
  answer is arbitrary because either could work). Also, there was a
  question of how it would work with *args (does it change the case with
  zero arguments as it does for the iterator case). When the choice of
  semantics are arbitrary, it is better not to guess and instead have the
  coder explicitly say what is supposed to happen.

• it isn't really needed, there are several existing ways to create the
  same effect.

• the meaning of "start" is ambiguous and arbitrary (is it a default
  value for an empty input or it is like adding an extra value to the
  input sequence). We could pick one of the two meanings but that doesn't
  help a coder or code reviewer remember which meaning was correct. To
  prevent bugs, it is better for the code to explicitly spell-out how the
  corner case is to be handled.

• in mathematical notation, I see the corner cases being handled by
  piecewise functions (if seq is empty, value is this, else compute
  min/max) instead of the notation trying to override the simple meaning
  of min/max.

• I haven't found precendents in any other language. Even if there
  were, we would still have the problem of too many features being loaded
  onto Python's min/max and the unclear semantics of how those features
  would interact.

Thank you for the feature request. Sorry, this one didn't pan out.