Raymond Hettinger added the comment:
I still think complicating the API isn't worth it. Of late, we've gotten in
the habit of a complexity to even the simplest of things.
In the case of sequences, we already have a reasonable solution:
low = min(seq) if seq else default
In the rarer case of non-sequence iterables, catching a Value error is the
traditional solution -- not pretty, but not difficult either.
In the past, Guido has rejected that notion of "add a default value to every
function than can raise an exception". For example, someone wanted to add a
get() method to lists so they could avoid catching an IndexError, something
like s.get(index, default). IIRC, his motivation was that "avoiding API
clutter" was more important than supporting an uncommon use case that already
had viable solutions using plain Python.
My own principle is that it is okay to add an initial extra feature to
function, but not multiple extra features. This becomes more important when
the function already has API issues.
The min() / max() functions started-out with an API problem because of their
dual signature: min(s) versus min(a, b, c). That creates an ambiguity in
that case of min(*t) where the result depends on the length of the input.
IMO, that issue would be exacerbated by the addition of a default argument
(i.e. it would tend to hide the error from test cases):
for t in [(10, 20, 30), (10, 20), (10,), ()]:
print min(*t, default=100)
Also, I don't think we should forget the lessons learned about adding
unnecessary arguments to functions. For example, we let someone add start and
end arguments to str.startswith() and str.endswith() because "it seemed more
parallel with str.find()" and because "someone wanted it once a piece of code
somewhere". The downside only became apparent later when there was a
legitimate real use case for another feature request: searching multiple
prefixes and suffixes. Because we had wasted the positional arguments, we
ended-up with the awkward str.startswith(str-or-tuple [,start [,end]])
signature. That is why we have to write, filename.endswith(('.py', '.pyc')).
The double parens are part of the cost of API bloat.
Lastly, when it comes to common-place functions like min() and max(), we can
assess needs easily by looking at what other languages have done. Looking at
Excel, SQL, Java, Haskell, C# etc, I don't see a precedent for this feature
request.
Grepping for min/max in my own code and third-party libraries, I don't see any
cases where the code had a need for this feature. If the need arises, it
certainly doesn't come of very often.
If you guys all think this is an good feature request, then by all means, go
ahead and add it. My recommendation is to show design restraint and refuse the
temptation to grow this already awkward API when you don't have to.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18111>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
