max(), sum(), next()

[Mensanator]

On Sep 10, 5:36 pm, Terry Reedy <tjre... at udel.edu> 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