gh-92871: Remove typing.{io,re} namespaces#92873
Conversation
|
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. |
gvanrossum
left a comment
There was a problem hiding this comment.
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. |
AlexWaygood
left a comment
There was a problem hiding this comment.
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 DeprecationWarnings 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 <[email protected]>
We do emit |
There was a problem hiding this comment.
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
DeprecationWarnings for these.We do emit
DeprecationWarnings, 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 <[email protected]>
hauntsaninja
left a comment
There was a problem hiding this comment.
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. |
Uh oh!
There was an error while loading. Please reload this page.