On 2/6/2022 4:44 PM, Christian Heimes wrote:
If I had the power and time, then I would replace urllib with a simpler,
reduced HTTP client that uses platform's HTTP library under the hood
(WinHTTP on Windows, NSURLSession (?) on macOS, Web API for Emscripten,
maybe curl on Linux/BSD). For non-trivial HTTP requests, httpx or
aiohttp are much better suited than urllib.
I'm +1 on this, though I think it would have to be in place before the
"two releases until removal" kicked in for urllib.request.
The stdlib can't get by without at least the basic functionality of curl
built in natively. But we can do this on most platforms without
vendoring OpenSSL, which is a HUGE win. Then our default behaviour could
correctly use proxies (including auto-config), CA certificate bundles,
integrated authentication, and other OS features that are currently
ignored by our core.
Chances are we could keep simple urlopen() calls in place, and use the
deprecation as a "potential change of behaviour" without necessarily
having to break the API. I'm yet to come across a case where making a
trivial urlopen() call _better_ would break things (the cases I've seen
that would break are things like "using an OpenSSL environment variable
to configure something that I wish had been automatic").
The nature of network/internet access is that we have to break things
periodically anyway, because all the code that was written over the last
30+ years is eventually going to be found to be exploitable. I'd be
quite happy to say "Python gives you what your OS gives you; update the
OS for fixes".
Cheers,
Steve
_______________________________________________
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/2P3RL7PAOZZFZ7PRGO6FJRMKR6MM2VXH/
Code of Conduct: http://python.org/psf/codeofconduct/