RetroSearch Browse

Sat Oct 25 08:39:12 EDT 2003 · https://mail.python.org/pipermail/python-dev/2003-October/039490.html

On Thursday 23 October 2003 03:43 am, Raymond Hettinger wrote:
> In the course of writing up Pep 289, it became clear that
> the future has a number of accumulator functions in store.
> Each of these is useful with iterators of all stripes and
> each helps eliminate a reason for using reduce().
>
> Some like average() and stddev() will likely end up in a
> statistics module.  Others like nbiggest(), nsmallest(),
> anytrue(), alltrue(), and such may end-up somewhere else.
>
> The product() accumulator is the one destined to be a builtin.
>
> Though it is not nearly as common as sum(), it does enjoy
> some popularity.  Having it available will help dispense
> with reduce(operator.mul, data, 1).
>
> Would there be any objections to my adding product() to
> Py2.4?  The patch was simple and it is ready to go unless
> someone has some major issue with it.

Michael has already quoted my April opinion on the subject.

I think these "useful accumulator functions" should all be in
some separate module[s]: none of them is nowhere near
popular enough to warrant being a built-in, IMHO.  If any were,
it might be "alltrue" and "anytrue" -- the short-circuiting ones,
returning the first true or false item found respectively, as in:

def alltrue(seq):
    for x in seq:
        if not x: return x
    else:
        return True

def anytrue(seq):
    for x in seq:
        if x: return x
    else:
        return False

these seem MUCH more generally useful than 'product' (but,
I still opine, not quite enough to warrant being built-ins).

Alex

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

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

[Python-Dev] product()