[issue14182] collections.Counter equality test thrown-off by zero counts
Stephen Webber added the comment:
Hmm, that is odd behavior indeed.
I think having keys that point to zero values is important for iterating over a
set. For example:
x = Counter(a=10, b=0)
for k in set(x):
... x[k] += 1
...
x
Counter({'a': 11, 'b': 1})
is probably preferable to
x = Counter(a=10, b=0)
for k in set(x):
... x[k] += 1
...
x
Counter({'a': 11})
Perhaps to ensure intuitive behavior we could ensure that
Counter(a = 3) + Counter(b = 0) == Counter(a = 3, b = 0)
True
by aggregating all keys into the new Counter object, even those with zero
values? I would be happy to make such a patch, as it would be good experience
for me to learn. Would this be an acceptable solution, and is there other odd
behavior at work here?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14182
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14182] collections.Counter equality test thrown-off by zero counts
Raymond Hettinger added the comment: At its most basic, a Counter is simply a dictionary with a __missing__ method that supplies a default of zero. It is intentional that everything else behaves as much like a regular dictionary as possible. You're allowed to store *anything* in the dict values even if those values don't represent numbers. A consequence is that equality is taken to mean the same a regular dict equality. The unary-plus is provided as a way to eliminate zeros from a Counter prior to doing a Counter equality test. Other designs were possible (such as my Bag class mentioned in the docs). This one was selected for its versatility, but it does present challenges with respect to zeros, negatives, fractions, etc. I recognize your concern but find it to be at odds with the basic design of the class. You might be happier with a Multiset class that restricts itself to positive integer counts. -- priority: normal - low resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14182] collections.Counter equality test thrown-off by zero counts
Eric Snow added the comment: I'd missed that unary + (new in 3.3). That's pretty cool. -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14182] collections.Counter equality test thrown-off by zero counts
Mark Dickinson added the comment: Raymond, Stephen's analysis seems correct. Are we missing something or can this issue be closed? Well, depending on how you think about Counters, the current behaviour of equality definitely leads to some surprises. For example: Counter(a = 3) + Counter(b = 0) == Counter(a = 3, b = 0) False OTOH, if we're consistent about regarding a count of 0 as 'equivalent' to a missing element, then __nonzero__ / __bool__ probably needs changing, too. c = Counter(a = 0) bool(c) True bool(c + c) False -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14182] collections.Counter equality test thrown-off by zero counts
Meador Inge added the comment:
Ah, good examples Mark. So, why is it ever useful keep a key with a value of
zero? In other words, why:
Counter(a=0)
Counter({'a': 0})
instead of:
Counter(a=0)
Counter()
?
The latter seems more consistent to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14182
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14182] collections.Counter equality test thrown-off by zero counts
Meador Inge added the comment: Raymond, Stephen's analysis seems correct. Are we missing something or can this issue be closed? -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14182] collections.Counter equality test thrown-off by zero counts
Stephen Webber added the comment: This is intentional handling of non-existant variables, and is not resticted to '==' operations. Returning the value of a Counter parameter that has not yet been set returns 0 by default. See the documentation here: http://docs.python.org/library/collections.html Counter objects have a dictionary interface except that they return a zero count for missing items instead of raising a KeyError: Since this is intended behavior, I recommend this bug become closed. -- nosy: +ForeverBacchus ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14182] collections.Counter equality test thrown-off by zero counts
New submission from Raymond Hettinger raymond.hettin...@gmail.com: from collections import Counter x=Counter(a=10,b=0,c=3) y=Counter(a=10,c=3) x == y False all(x[k]==y[k] for k in set(x) | set(y)) True -- assignee: rhettinger components: Library (Lib) messages: 154827 nosy: rhettinger priority: normal severity: normal status: open title: collections.Counter equality test thrown-off by zero counts type: behavior versions: Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
