[Python-Dev] Propose rejection of PEP 303 -- Extend divmod() for Multiple Divisors
Nick Coghlan
ncoghlan at gmail.com
Fri Jun 17 17:50:02 CEST 2005
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
More information about the Python-Dev
mailing list