This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: reduce docs neglect a very important piece of information.
Type: Stage:
Components: Documentation Versions: Python 2.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: jemfinch, rhettinger, terry.reedy
Priority: normal Keywords:

Created on 2003-10-11 10:59 by jemfinch, last changed 2022-04-10 16:11 by admin. This issue is now closed.

Messages (6)
msg18597 - (view) Author: Jeremy Fincher (jemfinch) Date: 2003-10-11 10:59
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.
msg18598 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2003-10-11 16:44
Logged In: YES 
user_id=80475

I've bumped into this also and always solved it by experiment.

I'll update the docs to clarity the situation.
msg18599 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2003-10-12 22:10
Logged In: YES 
user_id=593130

A draft of clarification text:

The rule is that the first (left) arg is the current cumulation 
and the second (right) is the update value from the 
sequence.  The initial cumulation is either the optional 
initializer or the first item of the sequence, at least one of 
which most exist to avoid a TypeError.

I inferred the left/right arg rule from '''
reduce(lambda x, y: x+y, [1, 2, 3, 4, 5]) calculates ((((1+2)
+3)+4)+5). ''' but an explicit statement would be helpful.
msg18600 - (view) Author: Jeremy Fincher (jemfinch) Date: 2003-10-13 14:35
Logged In: YES 
user_id=99508

I'd call the argument an "accumulator" rather than a
"cumulation."

The last sentence has a small typo, "at least one of which
most exist" instead of "at least one of which must exist."
msg18601 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2003-10-13 15:31
Logged In: YES 
user_id=593130

Revised clarification text to possibly add after current first 
sentence.

The first (left) argument is the accumulator; the second 
(right) is the update value from the sequence.  The 
accumulator starts as the initializer, if given, or as seq[0].  
An empty sequence with no initializer is a TypeError.

Follow this with the example.  I think the current wordier 
sentence about initialization could be deleted (or greatly 
reduced if above does not encompass all of current content).
msg18602 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2003-10-13 17:55
Logged In: YES 
user_id=80475

Fixed.
See Doc/lib/libfuncs.tex 1.150 and 1.143.8.6
History
Date User Action Args
2022-04-10 16:11:40adminsetgithub: 39392
2003-10-11 10:59:52jemfinchcreate