Python's simplicity philosophy

[John Roth]

"David Eppstein" <eppstein at ics.uci.edu> wrote in message
news:eppstein-1FB54D.10202111112003 at news.service.uci.edu...
> In article <lc4qxau8h7.fsf at gaffa.mit.edu>,
>  Douglas Alan <nessus at mit.edu> wrote:
>
> > "Dave Brueck" <dave at pythonapocrypha.com> writes:
> >
> > > Part of the problem here is that just saying "only one way to do it"
is a
> > > horrible misquote, and one that unfortunately misses IMO some of the
most
> > > important parts of that "mantra":
> >
> > Well, perhaps anything like "only one way to do it" should be removed
> > from the mantra altogether, since people keep misquoting it in order
> > to support their position of removing beautiful features like reduce()
> > from the language.
>
> I think the more relevant parts of the zen are:
> Readability counts.
> Although practicality beats purity.
>
> The argument is that reduce is usually harder to read than the loops it
> replaces, and that practical examples of it other than sum are sparse
> enough that it is not worth keeping it just for the sake of
> functional-language purity.

IMO, this arguement is basically religious, that is, it is not based
on common sense. Apply, lambda, map, filter and reduce never constituted
a complete set of functional programming constructs, so trying to
make them so for the sake of the arguement is, basically, silly.

Apply was absorbed into the language core with a small change
in function call specifications. Good idea - it gets rid of a built-in
function.
Map and filter were (almost) obsoleted by list comprehensions and the zip
built-in function. Whether or not list comprehensions are clearer than map
and filter is debatable, but the only thing we lost in the transition was
map's
capability of processing lists of different lengths.

Sum is not an adequate replacement for reduce, regardless of the
performance benefits. Something similar to a list comprehension would
be. I don't, at this point, have a good syntax to suggest though.

A not so good example would be:

numbers = [1, 2, 3, 4]
result = [x: x + i for i in numbers]

The ":" signals that the result is a single object, not a list of
objects. The first list element is bound to that label, and then
the expression is evaluated for the rest of the elements of the list(s).

The problem with the syntax is the brackets, which suggest that the
result should be a list.

John Roth

> -- 
> David Eppstein                      http://www.ics.uci.edu/~eppstein/
> Univ. of California, Irvine, School of Information & Computer Science