This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients gregory.p.smith, ncoghlan, oscarbenjamin, rhettinger, steven.daprano, wolma
Date 2017-10-29.02:23:24
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Thinking back to my signal processing days, I have to agree that our weightings (filter definitions) were usually separate from our data (live signals). Similarly, systems engineering trade studies all maintained feature weights separately from the assessments of the individual options.

The comment from my original RFE about avoiding expanding value -> weight/frequency mappings "to a full iterable all the time" doesn't actually make much sense in 3.x, since m.keys() and m.values() are now typically able to avoid data copying.

So +1 from me for the separates "weights" parameter, with the m.keys()/m.values() idiom used to handle mappings like Counter.

As another point in favour of that approach, it's trivial to build zero-copy weighted variants on top of it for mappings with cheap key and value views:

    def weighted_mean(mapping):
        return statistics.mean(mapping.keys(), mapping.values())

By contrast, if the lowest level primitive provided is a mapping based API, then when you do have separate values-and-weights iterables, you're going to have a much harder time avoiding building a completely new container.
Date User Action Args
2017-10-29 02:23:26ncoghlansetrecipients: + ncoghlan, rhettinger, gregory.p.smith, steven.daprano, oscarbenjamin, wolma
2017-10-29 02:23:26ncoghlansetmessageid: <>
2017-10-29 02:23:26ncoghlanlinkissue20479 messages
2017-10-29 02:23:24ncoghlancreate