[Python-Dev] Propose rejection of PEP 303 -- Extend divmod() for Multiple Divisors

[Nick Coghlan]

Raymond Hettinger wrote:
>>Plus, it fails the "not every 3-line function has to be a builtin"
>>guideline:
> 
> 
> Not to pick, but I hope this doesn't become a recurring refrain.  That
> isn't a real guideline, it's more of a snipe.  It also runs counter to
> Zen about proposals not being complex and being easy to explain.

I guess I really mean "the use case is obscure enough that simply 
writing the 5-line function is better than cluttering the API of a 
builtin", but that doesn't have quite the same ring to it ;)

>  There
> are tons of exceptions.  Guido's new any() and all() replace only a
> single line.  The sorted() builtin was very successful and it only
> replaced a couple of lines.  The key= argument is also successful but
> replaces a simple, three-line Schwarzian transform.  Reading DictMixin
> shows that most dictionary methods are trivially expressed in terms of a
> few primitives; however, we've learned that the mapping API is
> excellent, expressive, and useful (except for setdefault which I've
> grown to hate ;-).  IOW, the quip is food for thought but not
> necessarily either a positive or negative point about a proposal.

That's basically what I meant - and what I take the phrase to mean 
when someone else uses it.

If something is simple to write, but the use case is obscure, then 
that's an argument *against* making it a builtin, since half the time 
you'll have the function written before you remember there's a builtin 
for it. On the other hand, if the use case is common enough, rewriting 
it every time you need it is just a pain.

The 'not every . . .' comment just tries to say all that using only 
ten words.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com