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 mark.dickinson
Recipients Allen Downey, DavidMertz, josh.r, mark.dickinson, pitrou, rhettinger, serhiy.storchaka, steven.daprano, veky, wolma
Date 2018-05-18.07:40:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1526629217.91.0.682650639539.issue25478@psf.upfronthosting.co.za>
In-reply-to
Content
The point is that if you cache the total and update on each operation, you end up with a total that depends not just on the current contents of the Counter, but also on the history of operations. That seems like a bad idea: you could have two Counters with exactly the same counts in them (so that they compare equal), but with different cached totals.

So if floats (or Decimal instances) are permitted as Counter values, your suggested caching approach is not viable.

Of course, if Counter values are restricted to be plain old integers then it's fine, but that's not the current state of affairs.
History
Date User Action Args
2018-05-18 07:40:17mark.dickinsonsetrecipients: + mark.dickinson, rhettinger, pitrou, steven.daprano, serhiy.storchaka, wolma, josh.r, veky, Allen Downey, DavidMertz
2018-05-18 07:40:17mark.dickinsonsetmessageid: <1526629217.91.0.682650639539.issue25478@psf.upfronthosting.co.za>
2018-05-18 07:40:17mark.dickinsonlinkissue25478 messages
2018-05-18 07:40:17mark.dickinsoncreate