On Tue, 29 Mar 2022, 9:44 am Toshio Kuratomi, <a.bad...@gmail.com> wrote:
> One thing about talking about "make urllib more like requests" that is > different than any of the other libs, though, is that requests aims to be > easier to use than anything else (which I note Chris Barker called out as > why he wanted urllib to be more like it). I think that's important to > think about because i think ease of use is also the number one thing that > the audience you talk about is also looking for. > > Of course, figuring out whether an api like request's is actually easier > to use than urllib or merely more featureful is open to debate. > There's a concrete scope difference between the two: * requests was written as a way to make HTTP(S) requests from Python, including authenticated JSON based API requests * urllib was designed to work with a variety of URL schemas which may or may not support authentication and encryption (before the rise of the web and restrictive corporate firewalls helped HTTP become the de facto standard for data exchange over the public internet) I wrote more on that topic back in 2016 [1], and the gist of that article still holds true: urllib is OK for the basic HTTP GET use case, but having to tell urllib that you want to use HTTP-only features exposes a lot of low level plumbing that end users ideally wouldn't have to care about. Unfortunately, it isn't clear where a useful subset of a full-fledged HTTP client library lies. "Make it easy to send a TLS protected JSON API POST request with Basic authentication and check the status code of the response" *might* qualify, but even that isn't particularly easy to define or maintain (What about proxies? What about redirects? What about other authentication methods?). Thus the status quo persists - adding a fully featured HTTP client library to the existing stdlib maintenance burden doesn't (or at least shouldn't) strike *anyone* as a good idea, but it also isn't clear how much of the ease of use of the existing 3rd party libraries comes from the sheer amount of functionality they have built-in so users don't have to worry about it themselves, which means defining something "lighter and easier to maintain than a fully featured HTTP client library, but still easier to use than calling in to urllib directly" isn't a viable option either. At least with urllib present in the stdlib, it's *possible* to share "No dependency" recipes for crafting particular HTTP requests, even though the default recommendation remains to grab a higher level 3rd party library instead of rolling your own solution. Cheers, Nick. [1] https://www.curiousefficiency.org/posts/2016/08/what-problem-does-it-solve.html > -toshio > _______________________________________________ > 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/4ZQC4H7HD3UXFT3CONU64YPOQBSPUTVY/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/QENBMBYL4YABJKRPX7UR65DOGRAZUJ26/ Code of Conduct: http://python.org/psf/codeofconduct/
