On Sep 10, 5:36 pm, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Mensanator wrote:
> > Are there situations where the sum of an empty
> > list should NOT be 0? Of course there are.
>
> Python Philosopy (my version, for this discussion):
> Make normal things easy; make unusual or difficult things possible.
>
> Application:
> Sum([]) == 0 is normal (90+% of cases). Make that easy (as it is).
> For anything else:
> if seq: s = sum(s, base)
> else: <whatever, including like raise your desired exception>
> which is certainly pretty easy.
>
> > Can sum() handle those cases?
>
> The developers choose what they thought would be most useful across the
> spectrum of programmers and programs after some non-zero amount of
> debate and discussion.
>
> > No, it can't, I have to write
>
> > my own definition if I want that behaviour.
>
> Or wrap your calls. In any case, before sum was added as a convenience
> for summing numbers, *everyone* has to write their own or use reduce.
>
> 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
>>> S
<built-in function sum>
>>> s = [1,2,3]
>>> type(s)
<type 'list'>
>>> reduce(S,s)
Traceback (most recent call last):
File "<pyshell#13>", line 1, in <module>
reduce(S,s)
TypeError: 'int' object is not iterable
>>> reduce(S,s,0)
Traceback (most recent call last):
File "<pyshell#14>", line 1, in <module>
reduce(S,s,0)
TypeError: 'int' object is not iterable
>>> 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
This is supposed to happen. But doesn't reduce(S,s) work
when s isn't empty?
>
> However, a problem with reduce(S,s) is that it is *almost* the same as
> reduce(S,s,0). So people are sometimes tempted to omit 0, especially if
> they are not sure if the call might be reduce(S,0,s) (as one argument
> says it should be -- but that is another post). But if they do, the
> program fails, even if it should not, if and when s happens to be empty.
>
> > There's no reason
> > why sum([]) and sum([],0) have to mean the same thing at the
> > exclusion of a perfectly valid alternative definition.
>
> 'Have to', no reason. 'Should', yes there are at least three reasons.
> 1. Python functions generally return an answer rather than raise an
> exception where there is a perfectly valid answer to return.
> 2. As a general principle, something that is almost always true should
> not need to be stated over and over again. This is why, for instance,
> we have default args.
> 3. As I remember, part of the reason for adding sum was to eliminate the
> need (with reduce) to explicitly say 'start my sum at 0' in order to
> avoid buggy code. In other words, I believe part of the reason for
> sum's existence is to avoid the very bug-inviting behavior you want.
>
> Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
