Support for Counter objects

[matt035343]

Based on #363, I have resolved the conflicts and fixed a bug I found when updating the rest of the code base.

@n1chre please have a look.

[github-actions]

Coverage Report

File	Stmts	Miss	Cover	Missing
dataclasses_json
cfg.py	51	4	92%	80, 84–86
core.py	237	10	96%	38–41, 51, 64, 66, 81, 83, 169, 197
mm.py	202	30	85%	33–36, 42–45, 53–56, 62–65, 88, 161–162, 167, 171, 175, 180, 184, 188, 196, 202, 207, 216, 221, 226, 235, 244–251
stringcase.py	25	3	88%	59, 76, 97
undefined.py	143	2	99%	24, 38
utils.py	131	36	73%	12–25, 45–50, 61–65, 75, 100–101, 109–110, 125–133, 163, 182, 207
tests
entities.py	234	3	99%	22, 234, 240
test_annotations.py	81	42	48%	50–67, 78–102, 106–122
test_api.py	142	4	97%	88, 99, 139–140
test_str_subclass.py	22	1	95%	9
test_union.py	98	10	90%	87–94, 108–115
TOTAL	2503	145	94%

Tests	Skipped	Failures	Errors	Time
294	3 💤	0 ❌	0 🔥	5.858s ⏱️

[george-zubrienko]

https://docs.python.org/3/library/collections.html#collections.Counter

afaik typing.Counter is deprecated and Counter is just another python sugar for a dictionary type. Does this affect implementation, if taken into account?

[matt035343]

@george-zubrienko Since it is only the typing alias that is deprecated I can use collections.Counter instead. I still think support for Counter is relevant even though it is just a wrapper.

[george-zubrienko]

@george-zubrienko Since it is only the typing alias that is deprecated I can use collections.Counter instead. I still think support for Counter is relevant even though it is just a wrapper.

Yeah I do not deny this is needed, I'm just curious if we can fallback to code that handles dict instead of writing logic specific to Counter type, given this might break due to import being removed in future python versions?

[george-zubrienko]

Bless typing lib :D

[matt035343]

I will merge this by the end of this week unless @n1chre raises any concerns