-
-
Notifications
You must be signed in to change notification settings - Fork 30.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use type for deprecated aliases of typing instead of removing them #106745
Comments
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! |
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).
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/ |
… is not currently planned
@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:
|
To clarify: I am not asking for changes to past Python versions:
|
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? |
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 |
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. |
I'm not sure why you'd need a compatibility module unless you support a really exceptionally large range of Python versions. |
…aliases is not currently planned (python#106748)
The docs PRs have been merged, clarifying that:
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 :) |
…aliases is not currently planned (python#106748) (cherry-picked from commit 89ec0e9)
Enhancement
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: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:
What happens otherwise?
Examples:
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
The text was updated successfully, but these errors were encountered: