Python's simplicity philosophy

[Alex Martelli]

Douglas Alan wrote:
   ...
> Well, that's the argument you seem to be making -- that reduce() is
> superfluous because a sum() and max() that work on sequences were
> added to the language.

"added"?  'max' worked that way since well before I met Python.  But
to be consistent with your other arguments, no doubt you'd argue for
a .sort() followed by [-1] as "more general" than max...


>>> I can already see what's going to happen with sum(): Ultimately,
>>> people will realize that they may want to perform more general types
>>> of sums, using alternate addition operations.
> 
>> Not gonna happen - this _might_ happen if Python was a
>> design-by-committee language, but it's not.
> 
> According to Alex Martelli, max() and min() are likely to be extended
> in this fashion.  Why not sum() next?

I was just presenting my personal opinion regarding the fact that
the max and min functions should have an optional key= argument,
simply because the .sort method now (2.4) has one too.  If I implied
that anything I feel should be done is automatically "likely" to be
accepted by Guido, I apologize for mis-communicating; he throws stones
at far more of my ideas than he embraces.


>> To you, perhaps. Not me, and not a lot of other people.
> 
> Well, perhaps you can explain your confusion to me?  What could
> possibly be unintuitive about a function that is just like sum(), yet
> it allows you to specify the addition operation that you want to use?

Addition, as you have remarked elsewhere, is intrinsically suitable
for being applied to multiple operands; one is therefore naturally
disposed to think in terms of "add them all up", "sum them all", and
the like, NOT in terms of "iteratively perform 
    total = operator.add(total, item)
for all items in the sequence of numbers".  But, reduce as it exists
in Python today cannot be clearly defined EXCEPT by such an iteration
with some generic "callable which accepts two arguments" specified
in lieu of the operator.add.  Given this total generality, even though
hardly ever does it make sense to USE it, reduce becomes quite complex.

You've even argued in this thread, incorrectly, that reduce could be
eliminated if only all binary operators were able to accept arbitrary
numbers of arguments.  This, plus your insistence that 'reduce' is
"just like" APL's / (which does NOT accept arbitrary functions on its
left -- just specific operators such as +), indicate a _misconception_
of reduce on your part.  I'm sure you don't hold it consciously, but
these miscommunications indicate that even you, reduce's paladin, do
NOT properly grasp reduce "intuitively".

Having (e.g.) add accept a sequence argument (like max does), or, for
explicitness and potentially performance, grow an add.reduce attribute
just like in Numeric, would give no particular problems.  I'd still
want (just like Numeric does) to have sum as a name for add.reduce,
because it's by far the most common case and avoids getting into the
issue of what the (expletive delete) does "reducing" have to do with
anything that "add.reduce" does (it's really a curve ball compared
with the many meanings of "reduce" in English, after all).  But, most
importantly, such a design would avoid the veritable traps to which
the current, too-general 'reduce' subjects the poor learner who's
quite reasonably going to believe that all that generality MUST be
good for something if it's been designed into a built-in.  We've seen
quite a few such inappropriate uses on this thread, after all.

As I said, I'm not particularly good at guessing what Guido will or
won't bless, but I suspect that a patch to the operator module to
grow appropriate attributes on its functions, or even just make them
accept multiple arguments, might be well-received (to avoid wasting
work one might want a PEP or prePEP about that first, of course).


> Of course, you can get the same effect by defining a class with your
> own special __add__ operator, and then encapsulating all the objects
> you want to add in this new class, and then using sum(), but that's a
> rather high overhead way to accomplish the same thing that reduce()
> lets you do very easily.

In practice, I judge it quite unlikely that people will go out of their
way to abuse sum as I've seen them abuse reduce -- reduce lets you
abuse it very easily, as you mention, while sum needs you to really
jump through hoops to do so.


Alex