Erik Max Francis wrote: > Ron Adam wrote: > >> Each item needs to stand on it's own. It's a much stronger argument >> for removing something because something else fulfills it's need and >> is easier or faster to use than just saying we need x because we have y. >> >> In this case sum and product fulfill 90% (estimate of course) of >> reduces use cases. It may actually be as high as 99% for all I know. >> Or it may be less. Anyone care to try and put a real measurement on it? > > > Well, reduce covers 100% of them, and it's one function, and it's > already there.
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. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
