I suggest a `Counter.elements_count()` method should be added, that would give the same answer as `sum(counter.itervalues())`.

Thanks for the feature request.  Py3.3 is a long ways away, so I'll leave this open for a while.

Comments in favor:
* Precedent with Smalltalk bags that know their total length

Comments against:
* sum(c.values()) is trivial to write
* fattening the API makes it harder to learn and remember

It would be interesting to have Counter.elements_count() if it has a complexity of O(1): if the collections maintains a total (in a private attribute).

Otherwise, I think that sum(c.values()) is enough and can be documented as an example in the Counter doc.

> It would be interesting to have Counter.elements_count() 
> if it has a complexity of O(1): if the collections 
> maintains a total (in a private attribute).

I agree that it would be interesting; however, it would be an implementation disaster.  We would have to override (and slow-down) every mutating method in order to maintain the invariant.  And as a dict subclass, any C module using PyDict_Setitem() would bypass those methods and still break the invariant no matter what we do.

The Counter tool was designed in an open fashion (a simple, fully exposed dictionary with a few handy methods for counting).  In that regard, it is much different and more flexible than a traditional Bag class that maintains its data privately.

The name isn't meaningful to me. My preference would be for something like "total_count".

After more thought, I've decided to close this feature request.  The operation is utterly trivial and isn't worth fattening the API.  I see no advantage in `c.total_count()` versus `sum(c.values())`.