max(), sum(), next()

[bearophileHUGS]

Empty Python lists [] don't know the type of the items it will
contain, so this sounds strange:

>>sum([])

0

Because that [] may be an empty sequence of someobject:

>>sum(s for s in ["a", "b"] if len(s) 2)

0

In a statically typed language in that situation you may answer the
initializer value of the type of the items of the list, as I do in the
sum() in D.

This sounds like a more correct/clean thing to do:

>>max([])

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: max() arg is an empty sequence

So it may be better to make the sum([]) too raise a ValueError, in
Python 3/3.1 (if this isn't already true). On the other hand often
enough I have code like this:

>>max(fun(x) for x in iterable if predicate(x))

This may raise the ValueError both if iterable is empty of if the
predicate on its items is always false, so instead of catching
exceptions, that I try to avoid, I usually end with a normal loop,
that's readable and fast:

max_value = smallvalue
for x in iterable:
if predicate(x):
max_value = max(max_value, fun(x))

Where running speed matters, I may even replace that max(max_value,
fun(x)) with a more normal if/else.

A possible alternative is to add a default to max(), like the next()
built-in of Python 2.6:

>>max((fun(x) for x in iterable if predicate(x)), default=smallvalue)

This returns smallvalue if there are no items to compute the max of.

Bye,
bearophile

[Luis Zarrabeitia]

Quoting Mensanator <me********@aol.com>:

Actualy, I already get the behaviour I want. sum([1,None])
throws an exception. I don't see why sum([]) doesn't throw
an exception also

If you take a "start value" and add to it every element of a list, shouldthe
process fail if the list is empty? If you don't add anything to the startvalue,
you should get back the start value.

Python's sum is defined as sum(sequence, start=0). If sum were to throwan
exception with sum([]), it should also throw it with sum([], start=0), wich
makes no sense.

--
Luis Zarrabeitia
Facultad de Matemática y Computación, UH
http://profesores.matcom.uh.cu/~kyrie

[Mensanator]

On Sep 7, 3:38*pm, Luis Zarrabeitia <[e-mail]:

Quoting Mensanator <[e-mail]>:

Actualy, I already get the behaviour I want. sum([1,None])
throws an exception. I don't see why sum([]) doesn't throw
an exception also

If you take a "start value" and add to it every element of a list, shouldthe
process fail if the list is empty?

No.

If you don't add anything to the start value,
you should get back the start value.

Agree.

>
Python's sum is defined as sum(sequence, start=0).

That's the issue.

If sum were to throw an
exception with sum([]), it should also throw it with sum([], start=0), wich
makes no sense.

Given that definition, yes. But is the definition correct
in ALL cases? Are there situations where the sum of an empty
list should NOT be 0? Of course there are.

Can sum() handle those cases? No, it can't, I have to write
my own definition if I want that behaviour. There's no reason
why sum([]) and sum([],0) have to mean the same thing at the
exclusion of a perfectly valid alternative definition.

But that's the way it is, so I have to live with it.

But that's not conceeding that I'm wrong.

>
--
Luis Zarrabeitia
Facultad de Matemática y Computación, UHhttp://profesores.matcom.uh.cu/~kyrie

[Terry Reedy]

Mensanator wrote:

On Sep 10, 5:36 pm, Terry Reedy <[e-mail]:

>Sum(s) replaces reduce(lambda x,y: x+y, s, 0), which was thought to be
the most common use of reduce. Sum(s,start) replaces the much less
common reduce(lambda x,y: x+y, s, start).

Reduce(S, s), where S = sum function, raises an exception on empty s.
So use that and you are no worse off than before.

What am I doing wrong?

>>>S = sum

[snip]

Taking me too literally out of context. I meant the sum_of_2 function
already given in the example above, as you eventually tried.

def S(x,y): return x+y

Sorry for the confusion.

....

>>>reduce(lambda x,y:x+y,s)

6

>>>s=[]
reduce(lambda x,y:x+y,s)

Traceback (most recent call last):
File "<pyshell#17>", line 1, in <module>
reduce(lambda x,y:x+y,s)
TypeError: reduce() of empty sequence with no initial value

These two are exactly what I meant.

This is supposed to happen. But doesn't reduce(S,s) work
when s isn't empty?

It did. You got 6 above. The built-in 'sum' takes an iterable, not a
pair of numbers.

tjr

[Boris Borcic]

Tino Wildenhain wrote:

Hi,

Luis Zarrabeitia wrote:

>Quoting Laszlo Nagy <ga*****@shopzeus.com>:

...

>Even better:

help(sum) shows

===
sum(...)
sum(sequence, start=0) -value
Returns the sum of a sequence of numbers (NOT strings) plus
the value
of parameter 'start'. When the sequence is empty, returns start.
===

so the fact that sum([]) returns zero is just because the start value
is zero...
sum([],object()) would return an object().

BTW, the original code:

>>>>sum(s for s in ["a", "b"] if len(s) 2)

wouldn't work anyway... it seems that sum doesn't like to sum strings:

>>>>sum(['a','b'],'')

<type 'exceptions.TypeError'>: sum() can't sum strings [use
''.join(seq) instead]

Yes which is a bit bad anyway. I don't think hard wiring it is such a
nice idea. You know, walks like a duck, smells like a duck...
If it makes sense to handle things differently for performance, then
please have it doing it silently, e.g. when it detects strings just
use join() internally.

Cheers
Tino

+1

''.join is horrible. And it adds insult to injury that S.join(S.split(T)) != T
as a rule. The interpreter has no business to patronize us into this shamefully
contorted neighborhood while it understands what we want.

Cheers, BB

[Boris Borcic]

I wrote:

Tino Wildenhain wrote:

[...]

>>>>>sum(['a','b'],'')

<type 'exceptions.TypeError'>: sum() can't sum strings [use
''.join(seq) instead]

Yes which is a bit bad anyway. I don't think hard wiring it is such a
nice idea. You know, walks like a duck, smells like a duck...
If it makes sense to handle things differently for performance, then
please have it doing it silently, e.g. when it detects strings just
use join() internally.

Cheers
Tino

+1

''.join is horrible. And it adds insult to injury that
S.join(S.split(T)) != T as a rule. The interpreter has no business to
patronize us into this shamefully contorted neighborhood while it
understands what we want.

What makes ''.join particularly horrible is that we find ourselves forced to use
it not only for concatenating arbitrary-length strings in a list, but also to
convert to a str what's already a sequence of single characters. IOW string
types fail to satisfy a natural expectation for any S of sequence type :

S == type(S)(item for item in S) == type(S)(list(S))

And this, even though strings are sequence types deep-down-ly enough that they
achieve to act as such in far-fetched corner cases like

(lambda *x : x)(*'abc')==('a','b','c')

....and even though strings offer not one but two distinct constructors that play
nicely in back-and-forth conversions with types to which they are much less
closely related, ie.

'1j' == repr(complex('1j') == str(complex('1j'))
1j == complex(repr(1j)) == complex(str(1j))

Not-so-cheerfully-yours, BB