Python's simplicity philosophy

[SUZUKI Hisao]

All in all, I agree with you.  You have pointed out precisely
what has been making Python more attractive than, say, Perl.

In <lc65ho5g0n.fsf at gaffa.mit.edu>, you, Douglas Alan, wrote:
> The argument that some programmers might be too lazy to want to learn
> powerful, simple, and elegant features that can be taught in seconds,
> is no good reason to remove such features from Python and bloat Python
> by replacing them with a plethora of less powerful, less elegant
> features.

In <lcad73ye93.fsf at gaffa.mit.edu>, you also wrote:
> I like Python because it is a very simple, generic, easy-to-learn
> programming language, where I didn't have to learn much of anything
> new.  It was just like all the other myriad of programming
> languages I have programmed in, only less cluttered than most, and
> "light-weight" in its implementation and accessibility.

So do I.

As to sum(), when learning string addition (concatenation),
one may wonder why sum() does not handle it:

 >>> sum(['a', 'b', 'c'])
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
TypeError: unsupported operand type(s) for +: 'int' and 'str'

while general reduce() does it just as _expected_:

 >>> reduce(str.__add__, ['a', 'b', 'c'])
'abc'

It may be sum() that is more difficult to learn...

For this particular problem, it is better to use
''.join(['a', 'b', 'c']), you know.
However, it is important for Python to have an easy and generic
way to do things.  If we have to read the manual through to solve
anything, what is the point to use Python instead of Perl (or Ruby,
to some extent)?

> I having nothing against learning new stuff, by the way, but when I
> want to learn new stuff, I'm not particularly interested in the
> idiosyncrasies of Python -- I'd spend my effort learning something a
> bit more exotic, like OCaml, or Haskell, that might stretch my brain a
> bit.  Learning a bunch of idiosyncratic detail is just tedious.  This
> is one of the most important reasons that Perl sucks so badly.

Again in <lc65ho5g0n.fsf at gaffa.mit.edu>
> And as I have pointed out, it goes against the principle of simplicity
> and expressiveness to remove an easy to use and easy to learn simple
> and powerful feature with a slew of specific, tailored features.  If
> reduce() can be relegated to a library or for the user to implement
> for himself, then so can sum().  If the language is to only have one,
> it should be reduce().

I agree with you.

However, It may be better to give reduce() some nice notation.
Someone (sorry, but I do not remember) suggested such one:
[s: s+c for c in ['a', 'b', 'c']]
or
[s='': s+c for c in ['a', 'b', 'c']]
though it may not be the nicest.

-- SUZUKI Hisao