Use type for deprecated aliases of typing instead of removing them

[nineteendo]

Enhancement

This module (typing) defines several deprecated aliases to pre-existing standard library classes. ...
the aliases became redundant in Python 3.9 when the corresponding pre-existing classes were enhanced to support []. ...
The redundant types are deprecated as of Python 3.9 ...
(&) will be removed from the typing module no sooner than the first Python version released 5 years after the release of Python 3.9.0.
-- The typing documentation

Instead of removing these aliases, it would be more appropriate to redefine them using the type keyword added in 3.12 which shouldn't cause unnecessary overhead:

type Dict = dict
type List = list
...

And make type checkers warn users of the compatibility aliases that they are only to be used when aiming for backwards compatibility with Python version 3.5.4 - 3.8.

Pitch

These aliases were the only way to parameterise built-in classes in Python version 3.5.4 - 3.8. Completely removing them would suddenly break backwards compatibility with these versions for no good reason. This is especially relevant to third party modules that backport features from newer Python versions and pure python modules trying to support as many Python versions as possible.

A work-around would be to define a compatibility module, but that isn't a great solution as it adds unnecessary extra code & still requires modifying the code which could be cumbersome for large projects:

"""Typing compatibility module"""
from sys import version_info

__all__: list[str] = ['Dict', 'List', ...]

if version_info >= (3, 9):
   # TypeAlias & type can't even be used here because it they weren't available in 3.9 making this a suboptimal solution
   Dict = dict
   List = list
   ...
else:
   from typing import Dict, List, ...
   

What happens otherwise?

1. IDE's could give incorrect suggestions
2. Many older online tutorials become irrelevant.
3. Abandoned projects would become unusable

Examples:

• Python 3.5.4 - 3.8:

   from typing import List
   
   lst1: List[int] = [3, 1, 4, 1, 5, ...]
   lst2: list[int] = [3, 1, 4, 1, 5, ...] # TypeError: 'type' object is not subscriptable

• Python 3.9 - 3.X:

   from typing import List
   
   lst1: List[int] = [3, 1, 4, 1, 5, ...]
   lst2: list[int] = [3, 1, 4, 1, 5, ...]

• Python 3.Y - ∞:

   lst1: list[int] = [3, 1, 4, 1, 5, ...]
   
   from typing import List # ImportError: cannot import name 'List' from 'typing'
   
   lst2: List[int] = [3, 1, 4, 1, 5, ...]

No notation would be compatible with both 3.5.4 - 3.X & 3.Y - ∞

It's worth pointing out these aliases have been deprecated for quite some time. But as long as no irreversible decisions are made this remains open to discussion.

Previous discussion

Not applicable, this is an enhancement.

Linked PRs

• gh-106745: typing docs: Clarify that removal of PEP-585 aliases is not currently planned #106748
• [3.12] gh-106745: typing docs: Clarify that removal of PEP-585 aliases is not currently planned (#106748) #106772
• [3.11] gh-106745: typing docs: Clarify that removal of PEP-585 aliases is not currently planned (#106748) #106773

[AlexWaygood]

Hi @nineteendo! We have no plans to remove these aliases any time in the near future. The current documentation says that they will be removed from the typing module no sooner than the first Python version released 5 years after the release of Python 3.9.0. However, that's not the same thing as saying that we will remove these aliases in the first release 5 years after the release of Python 3.9.0 -- we will probably wait for quite a few more releases before even thinking about doing so. We're very aware that these aliases are very widely used, and there's not much benefit to removing them currently, so they'll definitely be around for a long while to come.

We can probably make this clearer in the documentation -- thank you for raising it!

[hugovk]

Even if they were removed in the first release 5 years after 3.9, that would be likely be 3.14, by which time the oldest supported Python would be 3.10.

That means all supported versions (3.10-3.14) have the new way of doing it, with an extra version as a buffer (3.9).

we will probably wait for quite a few more releases before even thinking about doing so.

And this would give an even bigger buffer.

---

PS It's irrelevant due to the long support window described by Alex, but it sounds like the proposal is asking to add aliases from 3.9 onwards. However, that's no longer possible, because we can only make security fixes to 3.9 and 3.10: https://devguide.python.org/versions/

[AlexWaygood]

@nineteendo, what are your thoughts on #106748? Does that PR clarify things to your satisfaction?

The intention is that you should not have to worry about changing your code for the foreseeable future:

• Removal of the aliases is not currently planned.
• If we decide at some point in the future that we'd like to remove the aliases, we would issue deprecation warnings at runtime for at least 2 releases (probably more) before actually removing them.
• We definitely won't start even issuing deprecation warnings for these aliases until after Python 3.9 becomes end-of-life.

[nineteendo]

PS It's irrelevant due to the long support window described by Alex, but it sounds like the proposal is asking to add aliases from 3.9 onwards. However, that's no longer possible, because we can only make security fixes to 3.9 and 3.10: https://devguide.python.org/versions/

To clarify: I am not asking for changes to past Python versions:

• TypeAlias has become deprecated, so it would even need a different solution than 3.12+
• The proposed changes are meant to avoid the need for removal (because they would add less overhead than the current implementation)

[nineteendo]

@nineteendo, what are your thoughts on #106748? Does that PR clarify things to your satisfaction?

OK, since depreciation warnings will be issued, I should have enough time to adjust my code and add a compatibility module when the aliases end up getting removed.

Thanks for clarification.

Will, the simplification of these aliases be considered?

[AlexWaygood]

• The proposed changes are meant to avoid the need for removal (because they would add less overhead than the current implementation)

If we were to decide that we wanted to remove these aliases, it would not be because of the overhead of these aliases. The maintenance costs of these aliases is already very low. They are also very cheap in terms of performance. These are two of the reasons why removal is not currently planned. Therefore, there would be little benefit in changing these aliases to use TypeAlias, as there isn't a problem that this would be solving.

[AlexWaygood]

OK, since depreciation warnings will be issued, I should have enough time to adjust my code and add a compatibility module when the aliases end up getting removed.

Since we are guaranteeing that they will definitely not be removed until long after Python 3.8 is end of life, there should be no need for you to ever add a compatibility module. When (if ever — and again, removal is not currently planned) you start seeing the deprecation warnings, you can switch to using the new syntax everywhere, without needing a compatibility module.

[JelleZijlstra]

I'm not sure why you'd need a compatibility module unless you support a really exceptionally large range of Python versions. list[int] works in 3.9 and up, and we won't even consider emitting DeprecationWarnings for List[int] until after 3.8 goes EOL. (And as Alex discussed, maybe not even then, as the maintenance overhead for keeping them around is low.)

[AlexWaygood]

The docs PRs have been merged, clarifying that:

• removal of the aliases is not currently planned
• we would issue deprecation warnings for at least 2 releases prior to removing them
• they are guaranteed to remain in the typing module without deprecation warnings until at least Python 3.14

I'm going to close this out now, as I don't think there's anything left to do here.

Thanks again for opening the issue, @nineteendo! The updates should appear in the online documentation in the next day or so :)