Python's simplicity philosophy

[Alex Martelli]

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.

Of course, net of multi-dimensional arrays, Numeric.sum does offer exactly
the same functionality as the built-in sum -- it's just slower for sequences
that are not Numeric.array's, faster for ones that ARE:

[alex at lancelot tmp]$ timeit.py -c -s'import Numeric'
'Numeric.sum(Numeric.arrayrange(234))'
10000 loops, best of 3: 30 usec per loop

[alex at lancelot tmp]$ timeit.py -c -s'import Numeric'
'sum(Numeric.arrayrange(234))'
10000 loops, best of 3: 79 usec per loop

So, the built-in sum is 2.5 times slower than Numeric.sum when the
sequence you're summing is a Numeric.array; but, vice versa:

[alex at lancelot tmp]$ timeit.py -c -s'import Numeric' 'sum(range(234))'
10000 loops, best of 3: 36 usec per loop
[alex at lancelot tmp]$ timeit.py -c -s'import Numeric'
'Numeric.sum(range(234))'
1000 loops, best of 3: 540 usec per loop

Numeric.sum is 15 times slower than the built-in sum when the sequence
you're summing is a list.

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


> I don't know that any conclusions would change with current Numeric
> functionality, and the effect of such changes on Numeric, taken under
> consideration.  But I do wonder why it doesn't seem to be condered
> essential to consider these kinds of issues in this light.

Numeric and numarray are designed and evolved by different groups of
people than those active on python-dev (with some overlap, of course).
They also address very different target audiences.  So, why would you
expect either group to be constrained (is that what you mean by
"considered essential"?) by design decisions made by the other...?

Maybe one day numarray will become part of the Standard python
libraries, and then everything will substantially change, of course.
But, until then, I do expect different evolution speeds and quite
possibly directions -- indeed, that's the _advantage_ of keeping
the two projects separate, avoiding excessive mutual constraints.


Alex