[issue36380] collections.Counter in-place operators are unexpectedly slow

Raymond Hettinger added the comment: FWIW, the promised semantics of saturating arithmetic require that _keep_positive be run on entire the entire counter: >>> c1 = Counter(a=-3, b=4) >>> +c1 Counter({'b': 4}) >>> from collections import Counter >>> c1 = Counter(a=-3, b=4

[issue36380] collections.Counter in-place operators are unexpectedly slow

Raymond Hettinger added the comment: I don't want to complexify the normal case. Please don't go down the path of turning something simple into a mess. Because counters are just a dict subclass, users are free to make updates in any way they want. -- __

[issue36380] collections.Counter in-place operators are unexpectedly slow

Rémi Lapeyre added the comment: Hi what do you think of a patch to this effect that would speed up operations without changing the current semantics? diff --git a/Lib/collections/__init__.py b/Lib/collections/__init__.py index cff75a48d6..fe5d5b2dca 100644 --- a/Lib/collections/__init__.py ++

[issue36380] collections.Counter in-place operators are unexpectedly slow

Raymond Hettinger added the comment: As Josh pointed out, this is how counters are documented and tested to work, so it is an unchangeable decision (i.e. it would break code that relying on the saturating arithmetic feature). Accordingly, I'm marking this as closed, not a bug. On the plus

[issue36380] collections.Counter in-place operators are unexpectedly slow

Change by Raymond Hettinger : -- assignee: -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue36380] collections.Counter in-place operators are unexpectedly slow

Josh Rosenberg added the comment: @Nikita: Your examples aren't unexpected at all, per the documented behavior: >Several mathematical operations are provided for combining Counter objects to >produce multisets (counters that have counts greater than zero). Addition and >subtraction combine c

[issue36380] collections.Counter in-place operators are unexpectedly slow

Karthikeyan Singaravelan added the comment: I would defer to Raymond at this point and would prefer keeping current __iadd__ behavior and . See also issue23509 that discussed about C implementation of _keep_positive and some other optimizations. > Counter(a=-1) + Counter(a=-2) produces empt

[issue36380] collections.Counter in-place operators are unexpectedly slow

Nikita Smetanin added the comment: @xtreak I agree, also, this behavior is stated in documentation, but it's quite inconsistent in many ways, like in the following examples: Counter(a=-1) + Counter(a=-2) produces empty Counter() instead of Counter(a=-2) which is unexpected, but Counter(a=-1)

[issue36380] collections.Counter in-place operators are unexpectedly slow

Rémi Lapeyre added the comment: @xtreak __init__ delegates work to update() which has the same behavior: Python 3.7.2 (default, Feb 12 2019, 08:15:36) [Clang 10.0.0 (clang-1000.11.45.5)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from collections import

[issue36380] collections.Counter in-place operators are unexpectedly slow

Karthikeyan Singaravelan added the comment: > It also unclear if there's even a need to check for non-positives with > _keep_positive in ops like __iadd__, __iand__ and __ior__ (except __isub__) > as it expects Counters which are always positive. Counter accepts dictionaries and keyword argu

[issue36380] collections.Counter in-place operators are unexpectedly slow

Change by SilentGhost : -- versions: -Python 3.5, Python 3.6 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36380] collections.Counter in-place operators are unexpectedly slow

Change by Karthikeyan Singaravelan : -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue36380] collections.Counter in-place operators are unexpectedly slow

New submission from Никита Сметанин : All of collections.Counter in-place operators: +=, -=, |= and &= are obviously expected to have time complexity O(b) as in the following example: a = Counter(...) # e.g 1M elements b = Counter(...) # e.g. 10 elements a += b But in fact, all of them are h