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 rhettinger
Recipients rhettinger, wpk-
Date 2020-05-25.17:23:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1590427419.37.0.676551375048.issue40764@roundup.psfhosted.org>
In-reply-to
Content
For the most part, Counter() works fine with negative counts.  The update() and subtract() methods were specifically designed to work with negative values.  Nothing prevents use cases with negative counts.

In addition, there are some methods like elements() that only make sense with positive counts.  So if your use case has negative counts, then these methods methods wouldn't be applicable.

Should the Counter() have been two different classes?  Maybe yes, maybe no.  But that ship sailed a long time ago.  For now, it is what it is and wouldn't be easy to change without breaking a lot of code.

From the outset, the central concept of Counter() is that it is a dictionary that returns zero when a value is missing.  Pretty much everything else is a set of convenience methods supporting all the different ways people aspire to use it (multisets, bags, counters, sparse arrays, etc).  People needing multiset methods use the multiset methods.  People want negative counts use the other methods.

Am marking this a closed.  There isn't much that can be changed here.  Also, theoretical objections aside, what we have now seems to be working well enough for most people most of the time.
History
Date User Action Args
2020-05-25 17:23:39rhettingersetrecipients: + rhettinger, wpk-
2020-05-25 17:23:39rhettingersetmessageid: <1590427419.37.0.676551375048.issue40764@roundup.psfhosted.org>
2020-05-25 17:23:39rhettingerlinkissue40764 messages
2020-05-25 17:23:39rhettingercreate