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.

Title: Counter with no keys does not compare equal to Counter with keys which zero value
Type: behavior Stage:
Components: Versions: Python 3.4, Python 3.5, Python 2.7
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: ethan.furman, josh.r, rhettinger
Priority: normal Keywords:

Created on 2014-10-01 19:49 by ethan.furman, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 20339 open rhettinger, 2020-05-24 01:22
Messages (5)
msg228111 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2014-10-01 19:49
According to the docs [1]:

> Counter objects have a dictionary interface except that they return a
> zero count for missing items instead of raising a KeyError

Which a simple test confirms:

--> Counter()['b']

However, if the key is present but set to zero, equality fails:

--> Counter() == Counter(b=0)

It is my thought that a Counter with all its keys set to zero is as empty as a Counter with no keys:

--> c1 = Counter()
--> c2 = Counter(a=0, b=0, c=0)
--> for item in c2.keys():
...   assert c2[item] == c1[item]
(no execption raised)

msg228130 - (view) Author: Josh Rosenberg (josh.r) * (Python triager) Date: 2014-10-01 22:05
Reading the note on the Counter class (about intent vs. actual use), it looks like changing this behavior would involve potentially breaking a lot of code.

If you're using Counters that are intended to maintain positive counts (treating a count <= 0 as if the key does not exist), it seems like you could either perform your operations using the + and - (or += and -=) binary operators (which will remove keys when the values drop to 0 or below) or if you have to use subtract or manual count tweaking, normalize the Counters at comparison time, that is, use +counter1 == +counter2 (unary + support added in 3.3).

I agree it's sort of weird, but I feel like fixing it will just break a ton of existing code.
msg228138 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2014-10-01 23:24
Exactly what operation is unary minus supposed to be?  It seems to act like absolute value.
msg228239 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2014-10-02 16:25
Ignore that last comment -- I don't know what I did yesterday, but unary minus is working as expected today.  :/
msg229064 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2014-10-11 07:19
> It is my thought that a Counter with all its keys set to zero 
> is as empty as a Counter with no keys

If the counter were a stand-alone multiset or bag class, this might be a reasonable thing to do.

However, for better or for worse, the design of the counter is primarily "a dict with a __missing__ that returns 0 and adds some handy methods useful in the context of dicts being used for counting".   This gives it flexibility, simplicity, speed, and makes it more or less substitutable for regular dicts in functions that expect regular dicts.  IIRC, this is the basic design that Guido endorsed when the idea of a counter was first proposed.

> I agree it's sort of weird, but I feel like fixing it will 
> just break a ton of existing code.

It is sort of weird, but that was the intended behavior (trying to keep the counter as dict-like as possible), and you're correct that changing it now would risk either breaking or substantially slowing code existing code.
Date User Action Args
2022-04-11 14:58:08adminsetgithub: 66723
2020-05-24 01:22:03rhettingersetpull_requests: + pull_request19607
2014-10-11 07:19:31rhettingersetstatus: open -> closed
resolution: not a bug
messages: + msg229064
2014-10-11 06:51:27rhettingersetassignee: rhettinger
2014-10-02 16:25:28ethan.furmansetmessages: + msg228239
2014-10-01 23:24:33ethan.furmansetmessages: + msg228138
2014-10-01 22:27:59ned.deilysetnosy: + rhettinger
2014-10-01 22:05:51josh.rsetnosy: + josh.r
messages: + msg228130
2014-10-01 19:49:03ethan.furmancreate