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 | [EMAIL PROTECTED] | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com