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.

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.

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 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.

Thanks, @vstinner and @gvanrossum, that was very helpful! I did run Victor's script for the top 5000 packages, and here are the results:

typing.re: Two affected projects (ignoring the typing backport):

• ktbyers/netmiko#2788
• wemake-services/wemake-python-styleguide#2414

A quick count show 7 affected projects for typing.io. I will send PRs later.

typing.io:

• facebookresearch/hydra#2218
• cognitedata/cognite-sdk-python#922
• pypa/pipenv#5106
• omry/omegaconf#936
• stix-patterns conditionally imports typing.io only on Python < 3.6.
• Same for antlr4-python3-runtime
• amazon-dax-client doesn't seem to have a public bug tracker, so I consider this Amazon's problem

Ignoring a Python 2 package and the typing backport.

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.