>> I also have no problem with inplace operators.  Or with adding
>> `Counter /= scalar", for that matter.

> But surely __rdiv__() would be over the top, harmonic means be damned ;-)

Agreed - itertools.Counter is the poster child for "practicality beats
purity" :-)

In context, the

    c *= 1 / c.total

example would clearly be useful at times.  But it's a strained way to spell

    c /= c.total

and, for float values, the former also introduces a needless rounding
error (to compute the reciprocal).

BTW, if _`Counter * scalar` is added, we should think more about
oddball cases.  While everyone knows what _they_ mean by "scalar",
Python doesn't.  The obvious implementation (Peter already gave it)
would lead to things like `Counter * Counter`, where both
multiplicands have integer values, yielding a Counter whose values are
also Counters.

That is, if

    c = Counter(a=1, b=2)
    d = Counter(a=3, b=4)

then c*d would yield a Counter mapping 'a` to 1 * d == d, and 'b' to 2
* d == Counter(a=6, b=8).

That's "bad", because the next suggestion will be that c*d return
Counter(a=3, b=8) instead.  That is, map a shared key to the product
of the values associated with that key.  For example, `c` is a Counter
tabulating category counts, and `d` a Counter giving category weights.

I don't suggest doing that now, but it would be nice to dream up a way
to stop "things like" Counter * Counter at the start so that backward
compatibility doesn't preclude adding sensible meanings later.
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to