Python's simplicity philosophy

[Terry Reedy]

"Patrick Maupin" <pmaupin at speakeasy.net> wrote in message
news:653b7547.0311121826.65b6b2d4 at posting.google.com...
> And then there are the corner cases, e.g. sum([]) vs.
> reduce(operator.add,[]) (which throws an exception).

The proper comparison is to reduce(operator.add, [], 0), which does
not throw an exception either.  sum(seq, start=0) is equivalent to
reduce(operator.add, seq, start=0) except that sum excludes seq of
string.  (The doc specifically says equivalent for number (int) seqs,
so there might be something funny with non-number, non-string seqs.)
In other words, sum is more-or-less a special case of reduce with the
within-context constants operator.add and default start=0 built in
(and the special special case of seq of strings excluded).

  I think it a big mistake (that should be repaired in 3.0) that the
result start value was made optional, leading to unnecessary empty-seq
exceptions.  I also think the order is wrong and should also be fixed.
I believe it was placed last, after the seq of update values,  so that
it could be made optional (which it should not be).  But it should
instead come before the seq, to match the update function (result,
seq-item) arg order.  This reversal has confused people, including
Guido.

> (Having said that, I never
> personally argued that reduce() should be removed from the language,
> but I do agree that it does not have to be part of "core" Python,
> and could easily be relegated to a module.)

If the builtins are reduced in 3.0, as I generally would like, I would
be fine with moving apply, map, filter, and a repaired version of
reduce to a 'fun'ctional or hof module.  But the argument of some
seems to be that this batteries-included language should specifically
exclude even that.

Terry J. Reedy