On 23 November 2014 at 12:51, Raymond Hettinger
For the reasons listed above, I prefer to be conservative and not expand the API further. For the most part, people seem to use counters for counting. They are good at that task and popular. I don't feel a strong need to expand the API into dodgy territory unless really good use cases arise to guide the design and make it feel like the added benefits were worth moving further on to shaky ground.
Also, I've taken some comfort in knowing that since a counter is a dictionary subclass, it is trivially easy to extend for users. If the user can already meet any perceived need by writing "all(c[k] < d[k] for k in c)", then I'm not sure we can make much of a value add.
You may not agree with the outcome of my thought process, but it is unfair to call it irrational.
Thanks for the detailed explanation.
not-everything-that-can-be-done-should-be-done-ly yours,
This is a key point. Providing APIs that have odd edge case behaviour can be worse than not providing a particular feature at all. When the feature doesn't exist, folks are more inclined to just write their own custom class or function that does exactly what they need. It's generally feasible to keep those quite concise, since they don't need to handle all possible variations that may arise. With the existing Counter-as-multiset features already offering some potential for confusion, and the potential for further confusing interactions between additional multiset features and Counter's support for non-integer values, zero values (distinct from keys being missing entirely) and negative values, there may be scope for a separate true multiset API that draws more heavily on the set API design than the dict API design. A dedicated multiset API would potentially be able to avoid the confusing aspects of Counters-as-multisets by only allowing non-negative integer values. Is there sufficient value in such an API to justify adding it? Or would it just create confusion as folks tried to decide between using Counter or using the new multiset/bag container for their algorithm? That's an open question, but at the very least, it's worth considering as an alternative to further elaborating on an already confusing aspect of the collections.Counter design. There's at least one such example of a bag API already available on PyPI: https://pypi.python.org/pypi/data-structures/0.1.4#bag (you need "-Counter" in a Google search to find that, as most current hits describe the use of Counter as a multiset, rather than using a dedicated container type) Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia