[Numpy-discussion] Simple multi-arg wrapper for dot()

[Bill Baxter]

On 3/25/07, Steven H. Rogers <steve at shrogers.com> 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