Make Counter generic over the value

[srittau]

Closes: #3438

[JelleZijlstra]

For what it's worth I think that's better than Never. We could test the value type with something like:

for value in Counter().values:
    assert_type(value, int)

[srittau]

Unfortunately, this makes pyright unhappy as well.

[srittau]

assert_type(Counter(), "Counter[Any, int]") works.

[JelleZijlstra]

At runtime this is actually an int though. I wonder if we need to make all these methods return _C | int.

[srittau]

This line should probably not be accepted, as Counter() is a Counter[unknown, int], which is incompatible with Counter[..., Foo]. I'm not sure the test makes much sense.

[JelleZijlstra]

Doesn't this sort of problem apply to any Counter with a non-int value type, though? This seems like a fundamental problem with this PR.

[srittau]

At runtime this is actually an int though. I wonder if we need to make all these methods return _C | int.

I wonder whether type checkers support __missing__, in which case, this should happen automatically when we add it to the stubs. But returning _C | int makes some sense to me for getter methods.

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

[srittau]

@erictraut: I'm unsure why pyright fails the test case as written: https://github.com/python/typeshed/actions/runs/8613668710/job/23605460935?pr=11632

custom_c = cast("Counter[str, Foo]", Counter())
# [...]
custom_c["a"] += 42  # type: ignore

pyright claims that the type ignore is unnecessary here, but unless I'm missing something, both __getitem__() and __setitem()__ are annotated to require a Foo instance, not int in this case.

[erictraut]

I'm not able to repro the problem when I copy and paste your modified definition of Counter along with the minimal test case snippet. When I do that, pyright generates an error for custom_c["a"] += 42 as I would expect. So there must be something else going on with your test if you're not seeing this error.

[srittau]

I remember that this is at least the second time, where a pyright "bug" can't be reproduced outside our CI environment. Something strange is going on with our CI it seems.