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@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com