This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients esam, phr, r.david.murray, rhettinger
Date 2009-10-18.19:26:08
SpamBayes Score 5.1292304e-14
Marked as misclassified No
Message-id <1255893971.09.0.68236209938.issue7153@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2009-10-18 19:26:12rhettingersetrecipients: + rhettinger, phr, r.david.murray, esam
2009-10-18 19:26:11rhettingersetmessageid: <1255893971.09.0.68236209938.issue7153@psf.upfronthosting.co.za>
2009-10-18 19:26:09rhettingerlinkissue7153 messages
2009-10-18 19:26:08rhettingercreate