PR 11359 has the following properties in its current state:

Performance vs naive implementation
-----------------------------------

./python -m perf timeit -s "import functools;import operator;iterable=list(range(10000))" 'functools.reduce(operator.mul, iterable, 1)'      .....................
Mean +- std dev: 654 us +- 15 us
./python -m perf timeit -s "import math;iterable=list(range(10000))" 'math.prod(iterable)'
.....................
Mean +- std dev: 72.3 us +- 1.1 us

./python -m perf timeit -s "import functools;import operator;iterable=list(map(float,range(10000)))" 'functools.reduce(operator.mul, iterable, 1)'
.....................
Mean +- std dev: 705 us +- 10 us

./python -m perf timeit -s "import math;iterable=list(map(float,range(10000)))" 'math.prod(iterable)'                                        .....................
Mean +- std dev: 52.9 us +- 2.0 us

./python -m perf timeit -s "import functools;import decimal;import operator;iterable=list(map(decimal.Decimal,range(10000)))" 'functools.reduce(operator.mul, iterable, 1)'
.....................
Mean +- std dev: 2.10 ms +- 0.03 ms

./python -m perf timeit -s "import math;import decimal;iterable=list(map(decimal.Decimal,range(10000)))" 'math.prod(iterable)'
Mean +- std dev: 1.12 ms +- 0.21 ms

Properties
----------

* It behaves with floats as numpy.prod:
   - A product of a finite floating-point (or convertible-to-float) numbers yields a float, nan or +-inf (no overflow checks).
   - A product involving infinities but no NaNs or zeros returns an appropriately-signed infinity.
   - A product involving both infinities and zeros (but not NaNs) returns 'NaN'.
   - A product involving a NaN at any point returns NaN.

* Is a implemented as general purpose function - like the built-in sum - as Tim is advising. It can multiply any Python type but has two fast-paths for floats and integers (or a mix of both).

-------------

In my humble opinion, any type-specialized implementation should exist in addition to this function (as fprod, iprod, scaledProd) while prod should remain as a general purpose function mirroring sum. Notice that people using numerical suites like numpy are used to the properties described in the previous paragraph and I think this is an advantage.

The main advantage of the function as it exists now in PR11359 is convenience and speed (almost 10x for fast paths and 2x for general types). I think this function will be very useful for scientific/statistical computing without the need for pulling in numpy and friends.

What do people think?