[Python-bugs-list] [ python-Bugs-821701 ] reduce docs neglect a very important piece of information.

[SourceForge.net]

Bugs item #821701, was opened at 2003-10-11 06:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821701&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
Assigned to: Nobody/Anonymous (nobody)
Summary: reduce docs neglect a very important piece of information.

Initial Comment:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821701&group_id=5470