I was writing a platform-independent hash function for
pathnames, and the documentation was useless for
determining in which order the arguments to the
reducing function are given.  In the one example given,
the arguments are of the same type, and the reducing
function uses a commutative operator, so it doesn't
matter.  In my case, however, I was doing this:

 >>> reduce(lambda h, s: h ^ hash(s),
s.split(os.path.sep), 0)
-740391245

where the arguments aren't the same type, so order does
matter.  I actually tried this first (since it's the
order of arguments of foldl in Haskell/SML):

>>> reduce(lambda s, h: h ^ hash(s),
s.split(os.path.sep), 0)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 1, in <lambda>
TypeError: unsupported operand type(s) for ^: 'str' and
'int'

Especially considering that the order of arguments here
is counter to the traditional order of arguments for
such functions in functional languages, I think there
should be a note in the documentation about the order
of arguments.