ast.pyi: add # type: ignore[deprecated] for type checker versions > requirements-tests.txt pinned versions

[hunterhogan]

Based on the existing usage of # type: ignore[deprecated] at

typeshed/stdlib/ast.pyi

Lines 2026 to 2036 in 49afeeb

	if sys.version_info < (3, 14):
	@deprecated("Replaced by visit_Constant; removed in Python 3.14")
	def visit_Num(self, node: Num) -> Any: ... # type: ignore[deprecated]
	@deprecated("Replaced by visit_Constant; removed in Python 3.14")
	def visit_Str(self, node: Str) -> Any: ... # type: ignore[deprecated]
	@deprecated("Replaced by visit_Constant; removed in Python 3.14")
	def visit_Bytes(self, node: Bytes) -> Any: ... # type: ignore[deprecated]
	@deprecated("Replaced by visit_Constant; removed in Python 3.14")
	def visit_NameConstant(self, node: NameConstant) -> Any: ... # type: ignore[deprecated]
	@deprecated("Replaced by visit_Constant; removed in Python 3.14")
	def visit_Ellipsis(self, node: Ellipsis) -> Any: ... # type: ignore[deprecated]

Added # type: ignore[deprecated] to the code block below # visit methods for deprecated nodes

typeshed/stdlib/ast.pyi

Lines 2018 to 2024 in 49afeeb

	# visit methods for deprecated nodes
	def visit_ExtSlice(self, node: ExtSlice) -> Any: ...
	def visit_Index(self, node: Index) -> Any: ...
	def visit_Suite(self, node: Suite) -> Any: ...
	def visit_AugLoad(self, node: AugLoad) -> Any: ...
	def visit_AugStore(self, node: AugStore) -> Any: ...
	def visit_Param(self, node: Param) -> Any: ...

Added # type: ignore[deprecated] and modified # type: ignore[misc]

typeshed/stdlib/ast.pyi

Lines 1182 to 1188 in 49afeeb

	@deprecated("Deprecated since Python 3.9. Use ast.Tuple instead.")
	class ExtSlice(slice):
	def __new__(cls, dims: Iterable[slice] = (), **kwargs: Unpack[_SliceAttributes]) -> Tuple: ... # type: ignore[misc]
	@deprecated("Deprecated since Python 3.9. Use the index value directly instead.")
	class Index(slice):
	def __new__(cls, value: expr, **kwargs: Unpack[_SliceAttributes]) -> expr: ... # type: ignore[misc]

[hauntsaninja]

What problem is this solving for you?

[hunterhogan]

What problem is this solving for you?

I am not sure I understand your question, however:

It suppresses those diagnostic reports when I am working with the file. https://github.com/hunterhogan/astToolkit

Hypothetically, but only hypothetically at this point, it could help here, too. https://github.com/hunterhogan/stubFileNotFound

[JelleZijlstra]

We add type ignores to silence errors from type checkers in our CI. They shouldn't matter if you merely use the ast library, since type checkers should not emit errors for lines in typeshed.

That's why Shantanu asked what problem this solves for you.

[hunterhogan]

We add type ignores to silence errors from type checkers in our CI.

Ah, that explains many things! I apologize for my ignorance causing extra work for y'all. Now that I understand the connections between the failed tests and other things, I can (and will) go learn some more things. Please give me a day to figure this out so it passes the tests.

[github-actions]

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

[hunterhogan]

The successful tests confirm that my Pull Request is less wrong than it was before. I changed the title to something better, but I suspect it needs improvement in ways I don't know about. I hope the content of the commits is now up to standards.

I am working directly with the stub file, so I see the diagnostic errors.

[srittau]

I'm still not sure what exactly your use case is, but any type checker should not warn about problems in third-party stub files (i.e. stubs from typeshed). We generally only add type ignores to stubs to satisfy our CI tests. In particular, the deprecation warnings should never be triggered, since the stubs themselves will never call any of the deprecated functions. If the deprecation warnings are triggered in your local project, you need to add the # type: ignore statements there or exclude the stubs from type checking if you are copying them to your project. I don't think these additional ignore statements are a benefit to the typeshed project.

[hunterhogan]

:(

I'm still not sure what exactly your use case is ...

To create the halfway decent tools in https://github.com/hunterhogan/astToolkit, I directly use the "ast.pyi" file.

https://github.com/hunterhogan/astToolkit/blob/e6abb1efd7860684abc1142381db3f922c5d8451/toolFactory/Z0Z_makeAstTools.py#L26-L32

Then I use inexpert programming skills to extract and transform the information.

https://github.com/hunterhogan/astToolkit/blob/e6abb1efd7860684abc1142381db3f922c5d8451/toolFactory/astFactory.py#L103-L111

I don't think these additional ignore statements are a benefit to the typeshed project.

You are probably right, but I'm not qualified to agree or disagree with you. I cannot think of a direct "benefit to the typeshed project." Furthermore, I cannot think of a direct benefit to those who use the typeshed project in a "normal" way.

I sincerely don't know whether a utilitarian analysis of this Pull Request would or would not suggest it should be merged. Because Shantanu asked and because you said you didn't know about the potential utility for me, I have tried to concisely explain it, above.

[JelleZijlstra]

I see, that's definitely an unusual use case. You're welcome to do that sort of thing, but it's not a use case we officially support, and if you're generating a patched version of _ast.pyi, it makes more sense for you to add any type ignores you need while patching.

[srittau]

That's a pretty cool use case for the type stubs – and helps me with my argument that stubs can be used in unexpected ways. But I agree with what Jelle wrote. This is also safer for your project as that use case is something that we're probably not keeping in mind when editing/improving our type stubs, so doing this yourself makes your project more resilient against changes on our side.