Document mypy version requirement in third-party stubs

[brian-kubisiak-skydio]

Change #6685 switched to using tuple[Any, ...] instead of Tuple[Any, ...] (and list instead of List) in the types-mock package. This feature is only available in python3.9+ (see: https://mypy.readthedocs.io/en/stable/builtin_types.html#generic-types), leading to spurious error: Tuple index out of range when type-checking under python3.8

[sobolevn]

Do you use mypy==0.930?

[brian-kubisiak-skydio]

Do you use mypy==0.930?

Using mypy==0.910.

[AlexWaygood]

If you upgrade to 0.930, mypy should be fine with the new syntax in stub files, even if you're running Python 3.8. Stub files have different rules to .py files.

[brian-kubisiak-skydio]

Thanks, mypy==0.930 seems to fix this issue. Might be worth calling out in documentation somewhere?

[Akuli]

I think it would be reasonable to document this somewhere, either stub-specifically or in a way that applies to all stubs. Even though mypy is just one of the tools that use typeshed, it is important.

[srittau]

stub_uploader could add a line "These stubs have been tested with mypy A.BCD, pytype YYYY.MM.DD, and pyright A.B.CDE." (gathered from requirements.txt and tests/pyright_test.py) to the description.

[Akuli]

When we edit requirements-tests.txt, should the uploader reupload all stubs only because the versions changed?

[srittau]

That shouldn't be necessary, I think, but I don't particularly mind either way.

[intgr]

Per #9690, I think it would be reasonable to have a grace period following a mypy release during which breaking changes in third-party stubs aren't released yet. Otherwise the breaking changes may make it harder to actually upgrade mypy in downstream projects.

[srittau]

It would be great if we could somehow encode breaking changes in the type stub version numbers, but I unfortunately don't see a good way to do that with the version number formats Python allows.

[hauntsaninja]

I think you could have an interleaved (upstream major).(typeshed major).(upstream minor).(typeshed minor)... version, and that would likely let you do pins that have semantic meaning. But such a versioning scheme would be very confusing for users, so they probably wouldn't do such pins in practice. It's also a little unclear what a semantic version would be for a type stub. So I'm -1 on my own idea.

[Avasam]

npm/node has optionalDependencies that can be specified in package.json. Allowing you to specify ranges on other co-installed dependencies, without forcing them to be installed.

Does python's requirements system / pip have a way to specify such dependencies? Maybe as extras?
The same idea could generally be useful in stubs to type and test optional dependencies without having the stubsuploader mark them as required dependencies of the stubs.

It wouldn't cover pyright, but honnestly there's not much that can be done there anyway given it's a node module. (and the only non-python-based python type checker afaik).
Edit: actually there's a python wrapper for pyright, so there's that.