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. -- Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis Every astronaut who goes up knows the risks he or she faces. -- Sally Ride -- http://mail.python.org/mailman/listinfo/python-list