On 3/25/07, Steven H. Rogers <[EMAIL PROTECTED]> wrote: > The generator expression PEP doesn't say this, but the Python 3000 > planning PEP (http://www.python.org/dev/peps/pep-3100/) has map() and > filter() on the 'to-be-removed' list with a parenthetic comment that > they can stay. Removal of reduce() is annotated as 'done'. My > recollection of GvR's comments at PyCon was that the status of map() and > filter() is still undecided.
Well, I'll be. That pep points to guido's blog which has this comment: """ So now reduce(). This is actually the one I've always hated most, because, apart from a few examples involving + or *, almost every time I see a reduce() call with a non-trivial function argument, I need to grab pen and paper to diagram what's actually being fed into that function before I understand what the reduce() is supposed to do. So in my mind, the applicability of reduce() is pretty much limited to associative operators, and in all other cases it's better to write out the accumulation loop explicitly. There aren't a whole lot of associative operators. (Those are operators X for which (a X b) X c equals a X (b X c).) I think it's just about limited to +, *, &, |, ^, and shortcut and/or. We already have sum(); I'd happily trade reduce() for product(), so that takes care of the two most common uses. The bitwise operators are rather specialized and we can put fast versions in a library module if there's demand; for shortcut booleans I have the following proposal. """ So basically reduce() is going away because Guido has trouble understanding it and because he can only imagine 7 possible ways under the sun to combine inputs associatively. Wow. --bb _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
