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

[George Sakkis]

On Thu, Apr 16, 2009 at 10:08 PM, Raymond Hettinger <python at 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