RetroSearch Browse

Sun Oct 26 11:23:25 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-October/039577.html

Hello,

On Sun, Oct 26, 2003 at 11:09:56AM +0100, Alex Martelli wrote:
> > Oh, but we all *did* think of it.  For strings. :-)

> ...  When X is intended as a number class, this
> asymmetry between multiplication and (e.g.) addition violates
> the principle of least surprise.

I must admit I was a bit surprized when I first tested sum(), without first 
reading its doc because I thought I knew what it should do.  I expected it to 
be a fast equivalent to:

def sum(seq, start=0):
  for item in seq:
    start = start + seq
  return start

or:

  reduce(operator.add, seq, start)

I immediately tried it with strings and lists.  I immediately thought about
lists because of their use of "+" for concatenation.

So it seems that neither strings nor lists are properly supported, neither
tuples by the way, and my opinion on this is that it strongly contradicts the
principle of least surprize.

I would not object to an implementation of sum() that special-case lists, 
tuples and strings for efficiency. (by which I mean I can contribute a patch)

> language or library feature.  The problem of the += loop on strings is
> essentially solved by psyco, which has tricks to catch that and make
> it almost as fast as ''.join; but psyco can't get into a built-in function
> such as sum, and thus can't help us with the performance trap there.

Supporing sum() in Psyco is no big issue, and it could help the same way as it
does for str.__add__.  (It is not explicitely supported yet, but it could be
added.)  Still I believe that getting the complexity right in CPython is 
important, when it can be done.

Armin

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-October/039577.html below:

[Python-checkins] python/dist/src/Python bltinmodule.c, 2.292.10.1, 2.292.10.2