On Thu, Apr 16, 2009 at 10:08 PM, Raymond Hettinger <python@rcn.com> wrote:

I did take time to scan the standard library and my own code base for examples.  They are *very* hard to come by. I couldn't even contrive an example for max(). The one use case presented so far is more cleanly coded with all() than with min().  The example isn't even remotely compelling.

Are you looking specifically for examples with non-sequence iterables ? As I mentioned, I would prefer "min(s, default=0)" from "min(s) if s else 0" if the former was available as it's more future-proof.

The code with a min default is unattractive by comparison:

 if min((f(x) for x in iterable if x>0), default=0) > 0:       ...

It is much better with:

 if all(f(x)>0 for x in iterable if x>0):          ...

Indeed, all() looks better in this case; maybe I was using the min value later and did it this way. I'll search for any actual examples as I recalled this from memory.

Besides use cases, my main objection is that it is poor design to overload too many features in one function.  If the existing signature for min() were just min(it), then it might not be an issue.  But the confluence of the multi-arg form, the exceptional zero-arg case, weirdness with *args, and the key= function make for little room to add new features.

That's a valid point, although the main mental burden lies in the multi-arg vs iterable single-arg peculiarity; optional keyword arguments scale better in general. As another aside, I'm curious of the relative frequency between the single-arg vs the multi-arg form. I personally use the former much more than multi-args, and for those it's almost always two args and very rarely three or more. Given that min(x,y) can be now written as an equivalent if/else expression, I'm wondering if the min/max signature would be the way it is if it was proposed now for the first time.

There is also the problem of confusing a default-argument with an initial start value.  When reading through code, my eyes would have a hard time accepting that min(it, default=0) could return something greater than zero.

Interesting, it took me a few seconds to think of why you might read it otherwise since it's "obvious" to me what it means. I had never thought of the initial value semantics wrt to min/max before this thread came up.

Did you look at the itertool alternative?  To me, it seems to cleanly separate concerns (computing the min/max from providing an iterator with a default value):

  min(default(iterable, 0))

Yes, that's neat, and default() may be a good candidate for addition to itertools.

I sense that you're going to try to force this through but wish

No, not at all. I'm not the OP and as I said, I have accepted that I should think of min/max more like division than a missing key/attribute. One can't just blindly use "min(x)" without considering the case where x is empty as he can't use 1/x without considering the case where x is zero. It's slightly inconvenient if all you have is a bunch of non-negative numbers and the "obvious" default is zero but generally explicit is better than implicit. George