Type annotation for collections.Counter looks doubtful

[fischbacher]

Right here, we find:

typeshed/stdlib/collections/__init__.pyi

Line 260 in 67c8584

class Counter(dict[_T, int], Generic[_T]):

Now, the standard library reference says:

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

-->
A Counter is a dict subclass for counting hashable objects. ...
...
Note Counters were primarily designed to work with positive integers to represent running counts; however, care was taken to not unnecessarily preclude use cases needing other types or negative values. To help with those use cases, this section documents the minimum range and type restrictions.
The Counter class itself is a dictionary subclass with no restrictions on its keys and values. The values are intended to be numbers representing counts, but you could store anything in the value field.
-->

So, overall, there are two relevant aspects here:

1. collections.Counter instances are dict instances, hence bound by the dict contract.
2. It is explicitly considered valid to have non-int values. (Due to 1., it would not be valid to forbid that - but it is also explicitly stated as permitted.)

This means that it is not valid to make a statement such as: "A collections.Counter[str] is a dict[str, int]". Rather, collections.Counter needs to be doubly-parametric (like dict) with respect to both key- and value-type:

A statement such as "A collections.Counter[str, numbers.Integral] is a dict[str, numbers.Integral]" would be typing-wise somewhat defensible. As long as we are not talking about mutability, it would be actually defensible. If we consider mutability, there is a separate issue, a revival of what has become known as "the ML reference problem" - but irrespective of that, collections.Counter cannot validly be singly-parametric with respect to key-type only.

[srittau]

Duplicate of #3438. This change would most likely break a lot of type annotations as long as we don't have type var defaults.