Add seaborn stubs

[hamdanal]

Requires

• Add matplotlib and pandas-stubs to the external requirements allowlist typeshed-internal/stub_uploader#102
• Add a "requires-python" metadata field in stub distributions typeshed-internal/stub_uploader#103
• Add optional requires_python to third party stubs metadata #10724

[AlexWaygood]

For the pytype_test.py failures, we'll probably need to make some adjustments to this function:

typeshed/tests/pytype_test.py

Line 152 in cecab9c

def _get_pkgs_associated_with_requirement(req_name: str) -> list[str]:

If need be, we could probably just add some hacky special-casing for pandas-stubs to the function, e.g.

if req_name == "pandas-stubs":
    return ["pandas"]

[AlexWaygood]

The mypy_test.py failures are harder to fix :(

We may need to consider adding a requires-python field to our METADATA.toml files, so we could declare that a stubs package only works with e.g. Python 3.9+. If we did that, it would enable us to skip running mypy with Python 3.8 for Seaborn in CI. But it would require also making some changes to the stub_uploader so that it includes the requires-python data in the setup.py files it generates.

[hamdanal]

The mypy_test.py failures are harder to fix :(

We may need to consider adding a requires-python field to our METADATA.toml files, so we could declare that a stubs package only works with e.g. Python 3.9+. If we did that, it would enable us to skip running mypy with Python 3.8 for Seaborn in CI. But it would require also making some changes to the stub_uploader so that it includes the requires-python data in the setup.py files it generates.

Thanks for looking into this. Should we open an issue about this to see what other maintainers say?

[AlexWaygood]

The mypy_test.py failures are harder to fix :(
We may need to consider adding a requires-python field to our METADATA.toml files, so we could declare that a stubs package only works with e.g. Python 3.9+. If we did that, it would enable us to skip running mypy with Python 3.8 for Seaborn in CI. But it would require also making some changes to the stub_uploader so that it includes the requires-python data in the setup.py files it generates.

Thanks for looking into this. Should we open an issue about this to see what other maintainers say?

Yes, that would be great!

[AlexWaygood]

I've triggered a rerun of the stub-uploader tests now typeshed-internal/stub_uploader#102 has been merged.

EDIT: They pass now; just mypy_test.py to go! 🚀

[AlexWaygood]

All green now 🥳 though I think we should also wait for typeshed-internal/stub_uploader#103 before we can consider merging this

[hamdanal]

I'll mark the PR as "Ready for review" because it is ready for review :P.
Maybe we can add a https://github.com/python/typeshed/labels/DO-NOT-MERGE or https://github.com/python/typeshed/labels/deferred label?

[AlexWaygood]

typeshed-internal/stub_uploader#103 was merged 🎉

[JelleZijlstra]

It seems like seaborn has a lot of inline types, and these stubs closely track them. Have you considered asking whether they would ship a py.typed? I don't see any discussion of that in their issue tracker.

[JelleZijlstra]

Thanks for clarifying, indeed the files outside _core are mostly not annotated. I reviewed up to cm.pyi now, mostly by spot-checking and reading along with the implementation.

[JelleZijlstra]

This check seems to indicate a broader type:

        if np.isscalar(x_vars):
            x_vars = [x_vars]

(Same for y_vars)

[hamdanal]

These are documented as "lists of variable names" but I annotated them as iterables because they are casted to list at runtime. The isscalar check seems to allow str to be accepted but this is already covered by Iterable[str]. I think no change is needed here?

[JelleZijlstra]

Doesn't feel great to rely on the fact that str is an Iterable[str], as usually that isn't what you want. As I recall pytype generally disallows str for Iterable[str]. So let's be explicit:

Suggested change

	x_vars: Iterable[str] | None = None,
	x_vars: Iterable[str] | str | None = None,

[JelleZijlstra]

Got to the end this time! A few more comments.

[github-actions]

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

[JelleZijlstra]

Thanks for your work @hamdanal!