[sns989]

requests, the python package for HTTP/S

[busterarm]

One of the most dumbfounding things I've encountered throughout my career is the python community's dogged persistence at avoiding using libcurl.

[posix_compliant]

Getting a resource in requests:

    import requests
    body = requests.get('http://pycurl.io/')

Getting a resource with libcurl:

    import pycurl
    from io import BytesIO
    
    buffer = BytesIO()
    c = pycurl.Curl()
    c.setopt(c.URL, 'http://pycurl.io/')
    c.setopt(c.WRITEDATA, buffer)
    c.perform()
    c.close()
    
    body = buffer.getvalue()

[detaro]

Doesn't answer the question why nobody has build an interface like the first example over the low-level libcurl bindings, or if someone has done so, why it hasn't been more popular.

I'd guess: because distributing packages with native dependencies is sort of a a pain, and was way worse in the past, especially cross-platform, and thus python-only packages are preferred. Leaves open why libcurl bindings weren't choosen for stdlib.

[busterarm]

Since we're on the topic of code quality, this example is an incredibly strong indication that you should be using an interface.

And while the requests library might be shorter/easier, it doesn't offer nearly the guarantees that it will exhibit the expected behavior nor the feature flexibility that libcurl does.

https://curl.haxx.se/libcurl/features.html

https://curl.haxx.se/libcurl/theysay.html

[j88439h84]

What are the advantages of using libcurl over whatever requests does?

[busterarm]

There is a very short list of projects that have had more engineering effort put into them than libcurl. Single digits. It's incredibly robust and battle-tested. Just about everything you could want to do with it performs as expected and is well-supported. On top of that, its performance is very good.

We're literally in the business of building on the work of others. Avoiding libcurl seems like an incredibly naive choice to me.