Add collections._tuplegetter support

[Gatsik]

Fixes #19414

Add TupleGetterType to describe NamedTuple's class variables

I could get away with some NotImplementedError's, and this is most likely because tests are not exhaustive, but I have no clue which use cases will trigger those methods

[brianschubert]

Thanks for working on this!

There should be no need to add a new type construct; descriptors like this can already be modeled by Instance.

I think it would be sufficient to make the field types instances of a collections._tuplegetter descriptor. Then mypy's existing descriptor handling will take care of the rest. The caveat is that collections._tuplegetter doesn't exist in the typeshed stubs, so someone would need to add it first. If you'd be interested in doing that, the functools.cached_property stubs work pretty similarly and can be used as a reference. Once collections._tuplegetter exists, the mypy implementation should be as simple as using self.api.named_type("collections._tuplegetter", [typ]) for the type.

[brianschubert]

Instead of replacing these fixtures and expanding fixtures/tuple.pyi, I'd suggest leaving them as-is and adding import collections to the fixtures that are used in named tuple tests. That should help reduce the diff

[brianschubert]

We don't need to be too detailed for the fixture. This should suffice, and will avoid the issues with introducing sys and Self:

class _tuplegetter(Generic[T]):
    @overload
    def __get__(self, instance: None, owner: type[Any]) -> _tuplegetter[T]: ...
    @overload
    def __get__(self, instance: object, owner: type[Any]) -> T: ...

[brianschubert]

Instead, let's add import collections to stubtest_typing_stub

[Gatsik]

There are some fixtures which break typegen tests having collections imported, that's why I initially decided to use tuple.pyi everywhere -- to stick to 1 approach.

But as you want to reduce diff 4 different solutions appear:

1. Import collections to some fixtures
2. Replace some fixtures from whatever to tuple.pyi and expand tuple.pyi
3. Create additional fixtures for some tests -- this is the case of list.pyi -- importing collections broke less typegen cases than not importing breaks namedtuple cases, so I decided to create a simpler version of list.pyi for typegen tests and replace less fixtures from list.pyi to list-simple.pyi rather than use the second approach for more cases
4. Modify broken typegen tests and add EllipsisExpr: ... (I don't remember actual output fully) to them, but it still modifies the same amount of typegen tests as in 3 but with bigger and meaningless diff, because EllipsisExpr are probably not what supposed to be tested in them

I hope this would be an acceptable compromise

[brianschubert]

Thanks, that's a much smaller diff! Your approach for the fixtures looks good. The important thing is that it's easy for a maintainer to see how the tests have changed. A smaller diff and less changes in the actual .test files helps with that :-)

To get the CI to run, you could try applying python/typeshed#14436 to mypy's vendored copy of typeshed at mypy/typeshed. We may or may not have to revert that before this PR can be merged, but for now it would be helpful to see if the tests run green and if there are any affected primer projects.

(also, can you update the PR title?)

[brianschubert]

For the mypyc test failures, try adding import collections to mypyc/test-data/fixtures/typing-full.pyi, and add the fixture [typing fixtures/typing-full.pyi] to the failing cases that don't already have it.

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅