Python's simplicity philosophy

[Arthur]

Alex wrote:

>Arthur wrote:

>> Rainer writes -
>>
>>>In one line:
>>>x = sum(seq)
>>>And that is why 'sum' is a worthwhile part of the Python >standard
library
>
>> The issue that concerns me is the analysis, decision-making on this kind
>> of issue on what is essentially an "as if" basis - as if Numeric and its
>> line of descent were not defacto standard library for numeric processing
>> in Python.

>Oh, they are -- particularly for _advanced_ array processing involving
>multi-dimensional arrays.  That's why I covered Numeric in the Nutshell.

[snip]

>I'm not sure what you're objecting to.  Is it the fact that the same
>name (built-in or within module Numeric) is used for very similar (but
>not identical, due to implementation optimizations -- as well as to
>multidimensional array issues) functionality?  To me, that seems a
>very good thing (that's part of why I never even considered other names
>for sum, such as add or total, when I first proposed it as a builtin).

Somebody was concerned enough to file a bug report on the naming of the
"sum"
built-in:

http://mail.python.org/pipermail/python-bugs-list/2003-June/018314.html

I am far removed from an indepth understanding of all the factors that led
to
the decision.  The net result confuses me, though. The simplicity
philosophy, to me,
says "what one naively might expect, is normally one gets".  The "sum"
built-in
does not violate that principle directly,  But does, indirectly, IMO.

IDLE 1.0
>>> a=[1,2,3]
>>> a*2
[1, 2, 3, 1, 2, 3]
>>> a/2

Traceback (most recent call last):
  File "<pyshell#2>", line 1, in -toplevel-
    a/2
TypeError: unsupported operand type(s) for /: 'list' and 'int'
>>> sum(a)
6
>>>

"sum" standalone is fine. But is unintuitively standalone. When one steps
back from the
trees a bit. IMO.

Art