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

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()

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.

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

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

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.