reduce()--what is it good for?

[Alex Martelli]

David C. Fox wrote:
   ...
>> However, so many of reduce's practical use cases are eaten up by sum,
>> that reduce is left without real use cases to justify its existence.
> 
> How about

...a typical example of *made-up* case follows...:

> import operator
> seq_of_flag_integers = [01020, 02300, 00132] #etc.
> reduce(operator.or_, seq_of_integers)
> 
> My simple timing tests (cumulative time for 1000 trials, each with a
> sequence of 1000 integers), show no significant difference between the
> above and an alternative using a for loop and |=, but the above is
> clearer to read.

You may consider it "clearer to read", and I might opine differently
(apart from the typo/bug that you're reducing a sequence you never
defined, of course:-).  That (necessary) trailing underscore in the
name of operator.or_ is quite unpleasant, for example.  But I think
the real point is another.

If you're doing lots of bit-twidding in Python, you surely need to learn
such Python constructs as for and |= anyway.

With these can't-avoid-learning-them constructs, you can obviously
code a simple, elementary loop such as:
    ored_flags = 0
    for flags in all_the_flags:
        ored_flags |= flags

Alternatively, you may learn _two more_ things -- that 'reduce' thingy
_plus_ the fact that module operator has an or_ function that does the
same job as | -- all in order to get an *equivalent* way to code the
same task?!  Not to mention that what you end up coding this way is most
definitely NOT going to be any clearer than the simple, elementary loop
to any future maintainer of your code -- if your bit-twiddling code is
going to be maintained by somebody who doesn't understand for or | you
are in trouble anyway, friend, while -- given that reduce and operator.or_
give NO real advantages! -- it WOULD be perfectly possible for your future
maintainer to NOT be familiar with them.


> I'm not claiming that the use case above is common, or particularly
> useful.  I'm just pointing out sum doesn't replace reduce unless the
> function being applied is addition.  Addition may be the most common
> case, and in that case, sum is both clearer and faster.  However, that
> doesn't detract from the clarity and usefulness of reduce in the
> remaining cases.

It's hard to detract from the clarity and usefulness of a construct
that never had much usefulness OR clarity in the first place.  When
we've taken away just about all of its reasonably frequent use cases,
what remains?  Essentially only a case of "more than one way to do-itis"
where in the "BEST" case the existence of 'reduce' and module operator
let you "break even" compared to elementary, simplest coding -- and
more often than not you can fall into traps such as those exemplified by
most reduce-defenders' posts on this thread.


> P. S. I've seen a lot of talk about removing old features from Python,
> or specifically old built-ins, because of bloat.  Does this "bloat"
> reduce performance, or does it refer to the extra burden on someone
> learning the language or reading someone else's code?

A slightly larger memory footprint, and larger built-ins dictionaries,
can only reduce runtime performance very marginally.  The "cognitive
burden" of having built-ins that "don't carry their weight", on the
other hand, is considered an issue *in Python*, because it doesn't fit
in with Python's general philosophy and worldview.  Python is meant to
be a LEAN language (with a not-lean standard library of modules that
are specifically imported when needed); certain "legacy" features are
sub-optimal (and best removed, when the strict constraint of backwards
compatibility can be relaxed) because they interfere with that (and
built-ins are close enough to "the core language" that they _do_ need
to be weighed severely in terms of "how often will they be useful").

It's a conceptual wart that the only sincere response to this thread
subject can be "not much, really -- basically backwards compatibility,
and some people's preference for constructs they're used to, often in
preference to simpler or better performing ones, some of which didn't 
happen to have been introduced yet when they learned Python"...:-).


Alex