-
-
Notifications
You must be signed in to change notification settings - Fork 30.7k
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
gh-92871: Remove typing.{io,re} namespaces #92873
Conversation
srittau
commented
May 17, 2022
•
edited
Loading
edited
- Issue: Remove typing.io and typing.re #92871
LGTM and I'm also +1 for this, but I'll wait to see what the rest have to say. |
Thanks, could you check whether there's any usage of these remaining in the wild? (cf. #92547 (comment)) |
Is there an easy way to do this? From what I understand, the scripts need a local copy of PyPI. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good riddance. Two tiny nits. When can we start deprecating typing.Pattern/Match and the io classes in typing?
Misc/NEWS.d/next/Library/2022-05-17-10-46-44.gh-issue-92871.GVogrT.rst
Outdated
Show resolved
Hide resolved
I'm usually in the "sooner better than later" camp, but for now I wouldn't recommend to more than soft-deprecate those, until Python 3.8 goes end of life. 3.9 introduced the generics in the stdlib, so to write code compatible with 3.8 and 3.9+, you'd need to use a conditional import otherwise. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one suggestion about a comment wording.
I also agree with @JelleZijlstra that we should check how much these are used in the wild before removing them, especially since we've never emitted DeprecationWarning
s for these. Some people use the objects in the typing
module for purposes other than static typing, so there might still be some people using these namespaces even though they've never been supported by type-checkers.
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
We do emit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also agree with @JelleZijlstra that we should check how much these are used in the wild before removing them, especially since we've never emitted
DeprecationWarning
s for these.We do emit
DeprecationWarning
s, starting with Python 3.11.
🤦♂️
I'd still like to double-check that there aren't too many uses of these in the wild, but providing there aren't, looks good!
Sounds like a good idea, if someone can do it and give me guidance on how to do it. |
I think @vstinner has a script to get the top 5k, but I can't find it documented. |
I wrote a different script: https://github.com/faster-cpython/tools/blob/main/scripts/download_packages.py |
I just documented it in my doc: https://pythondev.readthedocs.io/test_next_python.html#top-5000-pypi-packages I wrote these scripts for my own needs. It's based the script that @methane wrote to see how the PyUnicode C API was used. For example, search_pypi_top.py ignores Cython files (use |
Thanks, @vstinner and @gvanrossum, that was very helpful! I did run Victor's script for the top 5000 packages, and here are the results:
A quick count show 7 affected projects for |
Ignoring a Python 2 package and the typing backport. |
This makes for a total of 7 out of 5000 affected projects or 0.14%. |
@vstinner You mean beyond the PRs and issues linked above? |
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hooray! Shall we merge?
As far as I can tell we emit a DeprecationWarning only on 3.11, not 3.10. Therefore, following https://peps.python.org/pep-0387/#making-incompatible-changes we should wait until 3.13, not 3.12, to remove these. |
In that case we need to retroactively update the documentation, which says that they will be removed in Python 3.12. |
I wonder if there's any way to automate this, say, given some special tag for deprecation removals? |
The "What's new" comment needs to be moved to the 3.13 document when it becomes available. |
We're now ready to remove this in 3.13. @srittau do you want to update the PR? |
Move NEWS entry from 3.12 to 3.13.
Done, merged main and moved the NEWS entry in the process. |
Misc/NEWS.d/next/Library/2022-05-17-10-46-44.gh-issue-92871.GVogrT.rst
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @srittau!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM too :) thanks!