I've found some counterintuitive behavior in collections.Counter while hacking on the scikit-learn project [1]. I wanted to use a bunch of Counters to do some simple term counting in a set of documents, roughly as follows:

   count_total = Counter()
   for doc in documents:
       count_current = Counter(analyze(doc))
       count_total += count_current
       count_per_doc.append(count_current)

Performance was horrible. After some digging, I found out that Counter [2] does not have __iadd__ and += copies the entire left-hand side in __add__. I've attached a patch that fixes the issue (for += only, and I've not patched the testsuite.)

[1] https://github.com/scikit-learn/scikit-learn/commit/de6e93094499e4d81b8e3b15fc66b6b9252945af

This is slightly backwards incompatible, as some people may depend on the old behavior. Otherwise sounds like a good idea to me.

If this is not implemented because it is backwards incompat, then it might be useful to add a note to update's docstring explaining that it is much more efficient than +=. I was very surprised that it took *minutes* to add a few thousand moderate-sized Counters.

I'll add the in-place methods including __iadd__, __isub__, __iand__, and __ior__.

If speed is your issue, you should continue to use the update() method which will always be faster because it doesn't have a step to strip zeros and negative values from the existing Counter.  Also, update() has a fast-path written in C.

New changeset 5cced40374df by Raymond Hettinger in branch 'default':
Issue #13121: Support in-place math operators for collections.Counter().
http://hg.python.org/cpython/rev/5cced40374df

messages: + msg145071

messages: + msg145065

stage: patch review