Avoid using deprecated typing aliases in `importlib`

[Wulian233]

Feature or enhancement

Proposal:

In the documentation it is written:
https://docs.python.org/3.14/library/typing.html#deprecated-aliases

The redundant types are deprecated as of Python 3.9. However, while the aliases may be removed at some point, removal of these aliases is not currently planned. As such, no deprecation warnings are currently issued by the interpreter for these aliases.

If at some point it is decided to remove these deprecated aliases, a deprecation warning will be issued by the interpreter for at least two releases prior to removal. The aliases are guaranteed to remain in the typing module without deprecation warnings until at least Python 3.14.

---

For importlib, there are already type annotations, and in the previous discussion it was felt that type annotations should be kept
See https://discuss.python.org/t/static-type-annotations-in-cpython/65068

Where we are now, though, is that we have several bits and pieces of CPython that do use type annotations, and to good effect...

I'd like to clean up typing aliases that have been deprecated since python 3.9, although they won't have warnings at the moment. However, in the long run, for example, if a deprecation warning is prompted after 5 years, it will be a burden on the maintenance of stdlib.

For example, from typing import List
It can be replaced with a list of _builtin

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

Linked PRs

• gh-129490: Avoid using deprecated typing aliases in importlib #129491

[sobolevn]

It feels like it might be doing a lot of work for no big reason (yet). For example, 3.9 still receives security patches. It can create more churn and more conflicts.

[Wulian233]

There aren't many cases where the stdlib contains deprecate aliases, and I've only found importlib so far. I also hope that it will not cause conflict and have as little impact as possible. Personally, I think importlib will have fewer security fixes(probably not true)

[AlexWaygood]

It feels like it might be doing a lot of work for no big reason (yet). For example, 3.9 still receives security patches. It can create more churn and more conflicts.

I think all the proposed changes in #129491 are compatible with Python 3.9, since PEP-585 was implemented in Python 3.9. But I agree that this might cause complications with syncing code between CPython and the importlib_metadata backport package. We should defer to @jaraco on whether this is worth it.

[jaraco]

I answered in #129491 (comment). Short answer is that for this kind of change, contribution to the third-party packages would be preferred. Thanks for understanding.

Hi everyone,

I really appreciate the effort that has gone into identifying and addressing deprecated typing aliases in importlib. It’s great to see discussions around keeping the codebase aligned with modern Python standards.

That said, I noticed that the deprecated aliases are still guaranteed to remain in the standard library without warnings until at least Python 3.14, and Python 3.9 continues to receive security patches. Given this, would it be more practical to first apply these changes in third-party packages, as @jaraco suggested, before making updates in CPython?

I’d love to hear your thoughts on the best approach here. Thanks again for all your hard work in improving CPython!