Python's simplicity philosophy

[Alex Martelli]

Robin Becker wrote:
   ...
> on oop in this thread nobody has pointed out that we could have
> 
> sequence.sum()
> sequence.reduce(operator.add[,init])
> 
> or even
> 
> sequence.filter(func) etc etc
> 
> and similar. That would make these frighteningly incomprehensible ;)
> concepts seem less like functional programming. Personally I wouldn't
> like that to happen.

Maybe nobody "pointed it out" because it's utterly absurd to even
conceive of somehow magically adding all of those methods to *EVERY*
iterator under heavens?!  E.g., today, this works just fine:

>>> class BAH(object):
...     def __init__(self): self.seq = [1, 5, 3, 7, 19]
...     def __iter__(self): return self
...     def next(self):
...         try: return self.seq.pop()
...         except IndexError: raise StopIteration
...
>>> sum(BAH())
35

having instances of class BAH automagically spout such methods as
.sum(), etc, would be an absurdity.

Numeric's design -- considering that *functions* able to do .reduce
and the like are very special and should expose those as methods
(they're known as "ufuncs" in Numeric), taking the array as argument,
is a design which looks quite sound to me.  So, for example,
Numeric.sum(x, axis) boils down (after some error checks &c) to
Numeric.add.reduce(x, axis) [summing, of course, IS by far important
enough that having to spell it out as add.reduce would be silly].


Alex