On Sun, 3 Jul 2005, Robert Kern wrote: > Erik Max Francis wrote: >> Ron Adam wrote: >> >>> So you are saying that anything that has a 1% use case should be included >>> as a builtin function? >>> >>> I think I can find a few hundred other functions in the library that are >>> used more than ten times as often as reduce. Should those be builtins >>> too? >>> >>> This is a practical over purity issue, so what are the practical reasons >>> for keeping it. "It's already there" isn't a practical reason. And it >>> covers 100% of it's own potential use cases, is circular logic without a >>> real underlying basis. >> >> But the Python 3000 plan, at least what we've heard of it so far, isn't >> to move it to a standard library module. It's to remove it altogether, >> replacing it with sum and product. Since sum and product don't cover >> all the uses cases for reduce, this is a case of taking one function >> that handles all the required use cases and replacing it with _two_ >> functions that don't. Since it's doubling the footprint of the reduce >> functionality, arguments about avoiding pollution are red herrings. > > Four, in fact. sum(), product(), any(), and all().
I'll just chip in and say i'd quite like a flatten(), too; at the moment, i have one like this: def flatten(ll): return reduce(lambda a, l: a.extend(l), ll, []) A builtin, which had fast special-case code for then the argument is a list of lists (rather than an iterable of iterables), would be nice, since this is a reasonably big use of reduce for me. How would one do that as a list comp, by the way? I'm really not very good with them yet. > [1] Okay, there was that guy who predicted that list comprehensions and > first-class functions were the next to go. That was new. But also wrong. > I think we can discount that. True. Guido will only get rid of those after he's got rid of lowercase letters in identifiers. tom -- A military-industrial illusion of democracy -- http://mail.python.org/mailman/listinfo/python-list