That was just one example, here are others in the pip code base that urllib.request is used for more than the pathname functions, they are all vendored or tests but would still be disruptive to remove:
https://github.com/pypa/pip/blob/main/tests/lib/local_repos.py https://github.com/pypa/pip/blob/main/src/pip/_vendor/webencodings/mklabels.py https://github.com/pypa/pip/blob/main/src/pip/_vendor/requests/compat.py https://github.com/pypa/pip/blob/main/src/pip/_vendor/distlib/compat.py In particular the vendored library, and replacement you suggest, "requests" is very dependent on the proxy functions such as "getproxies" that are currently in urllib.requests. More than once I've had to go down the rabbit hole of seeing where those functions get that info for each platform. Damian (he/him) On Sun, Feb 6, 2022 at 11:10 AM Victor Stinner <vstin...@python.org> wrote: > On Sun, Feb 6, 2022 at 3:48 PM Damian Shaw <damian.peter.s...@gmail.com> > wrote: > > > > Pip vendors requests for network calls: > https://github.com/pypa/pip/tree/main/src/pip/_vendor/requests > > > > But still does depend on functions from urllib.parse and urllib.request > in many places: > https://github.com/pypa/pip/blob/main/src/pip/_internal/utils/urls.py > > Aha, it doesn't use urllib.request to open a HTTP connection, it only > uses pathname2url() and url2pathname() functions of urllib.request. > Maybe we can keep these functions. I'm not sure why they don't belong > to urllib.parse. > > If urllib.parse is widely used, maybe we can keep this module. > > Victor >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ACA7AU4W6XB35PA6O4IYBPQSQD3HFLFS/ Code of Conduct: http://python.org/psf/codeofconduct/
