Python's simplicity philosophy

[Patrick Maupin]

"Terry Reedy" wrote:
> "Patrick Maupin" wrote:
> > 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 agree.  Please remember that my post was arguing that it would
take more than 30 seconds to teach someone reduce() instead of sum().
This is precisely because sum() was deliberately chosen to special-case
the most common uses of reduce, including not only the add operator,
but also the default initial value.

>   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.

That makes some sense, but you'd _certainly_ have to move and/or rename
the function in that case.  There's breaking some backward compatibility,
and then there's taking a sledgehammer to things which used to work
perfectly.

As an aside, if sum() grew an optional _third_ parameter, which
was the desired operator, sum() would FULLY recreate the functionality
of reduce(), but with the same default behavior that was deemed
desirable enough to create the sum() function.  This is similar to
your preferred form in that the starting value is not optional
when you specify the operator (simply because you have to use
three parameters to specify the operator), differing only in
the order of the first two parameters.

Although this is not quite your preferred form, perhaps those in such
a rush to remove reduce() should consider this slight enhancement to
sum(), to mollify those who don't want to see the functionality disappear,
but who could care less about the name of the function which provides
the functionality (e.g. sum(mylist,1,operator.mul) is slightly
counterintuitive).

> 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.

I'm taking a wait-and-see attitude on this.  I don't think any of the
implementers have such a vested interest in being "right" that these
functions will be removed at all cost. As soon as the implementers
start porting their _own_ code to 3.0, I believe we'll starting getting
useful feedback, either of the form "itertools et al. has everything
I need", or "boy, this SUCKS!  I really need map!"

(I'm curious, though, why you included "apply" in this list.  I've
personally never needed it since the * enhancement to the call syntax.)

Regards,
Pat