gh-92871: Remove typing.{io,re} namespaces by srittau · Pull Request #92873 · python/cpython
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
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))
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.
Good riddance. Two tiny nits. When can we start deprecating typing.Pattern/Match and the io classes in typing?
When can we start deprecating typing.Pattern/Match and the io classes in typing?
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.
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 <Alex.Waygood@Gmail.com>
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 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!
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 think @vstinner has a script to get the top 5k, but I can't find it documented.
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 --cython option to not exclude them: see --help). Previously, I used rg for code serach, but it doesn't give the filename inside an archive and it doesn't show the matching line. Also, I needed something more specific to Python.
This makes for a total of 7 out of 5000 affected projects or 0.14%.
It would be nice to notify all these affected projects that they are not compatible with the future Python 3.12 which will be released in October 2023, or even propose PRs. Simply replacing typing.re with typing drops support with Python 3.7 and older? Is there a way to remain compatible with older Python versions?
@vstinner You mean beyond the PRs and issues linked above? typing.re and typing.io hasn't been necessary since at least Python 3.6, if ever. I don't think typeshed ever supported those namespaces.
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>