max(), sum(), next()

[Mensanator]

On Sep 6, 11:05�pm, Steven D'Aprano <st... at REMOVE-THIS-
cybersource.com.au> wrote:
> On Sat, 06 Sep 2008 11:22:07 -0700, Mensanator wrote:
>
> [...]
>
> >> They could have decided that sum must take at least two arguments,
> >> because addition requires two arguments and it's meaningless to talk
> >> about adding a single number without talking about adding it to
> >> something else. But they didn't.
>
> > Ok. But the problem is they DID in SQL: x + Null = Null.
>
> Sheesh. That's not a problem, because Python is not trying to be a
> dialect of SQL.

And yet, they added a Sqlite3 module.

>
> If you want a NULL object, then there are recipes on the web that will
> give you one. Then all you need to do is call sum(alist or [NULL]) and it
> will give you the behaviour you want.

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 (I understand that behaviour is by design,
I'm merely pointing out that the design doesn't cover every
situation).

>
> [...]
>
> > Here's a real world example (no ivory tower stuff):
>
> > An oil refinery client has just excavated a big pile of dirt to lay a
> > new pipeline.
> [snip details]
> > Can't I just use a sum of 0 to tell me when data is missing? No, because
> > in some cases the reporting limit of undetected compounds is set to 0.
>
> You can't use a sum of 0 to indicate when data is missing, full stop.

Exactly. That's why I would prefer sum([]) to raise an
exception instead of giving a false positive.

> The
> data may require 15 tests when only 3 have actually been done:
>
> sum([1.2e-7, 9.34e-6, 2.06e-8])

Biggest problem here is that it is often unknown just
how many records you're supposed to get from the query,
so we can't tell that a count of 3 is supposed to be 15.

>
> Missing data and a non-zero sum. How should sum() deal with that?

That's a seperate issue and I'm not saying it should as
long as the list contains actual numbers to sum.
sum([1.2e-7, 9.34e-6, 2.06e-8, None]) will raise an
exception, as it should. But what types are contained
in []?

>
> The answer is that sum() can't deal with that. You can't expect sum() to
> read your mind, know that there should be 15 items instead of 3, and
> raise an error. So why do you expect sum() to read your mind and
> magically know that zero items is an error, especially when for many
> applications it is NOT an error?

For the simple reason it doesn't have to read your mind,
a mechanism has already been built into the function: start
value. For those situations where an empty list is desired
to sum to 0, you could use sum(alist,0) and use sum(alist) for
those cases where summing an empty list is meaningless.
Shouldn't you have to explicitly tell sum() how deal with
situations like empty lists rather than have it implicitly
assume a starting value of 0 when you didn't ask for it?

>
> The behaviour you want for this specific application is unwanted,
> unnecessary and even undesirable for many other applications. The
> solution is for *you* to write application-specific code to do what your
> application needs, instead of relying on a general purpose function
> magically knowing what you want.

Does division magically know what you want? No, it raises an
exception when you do something like divide by 0. Isn't it
Pythonic to not write a litany of tests to cover every
possible case, but instead use try:except?

But try:except only works if the errors are recognized.
And sum() says that summing an empty list is NEVER an error
under ANY circumstance. That may be true in MOST cases, but
it certainly isn't true in ALL cases.

>
> --
> Steven