"So, instead of taking the WebOb approach of using WSGI as the common protocol between services, why not use HTTP itself? The rest of the world uses HTTP as the most-common denominator after all."

I agree with the assertion that HTTP is the most common denominator.

# done from memory

   In [1]: from webob import Request

   In [2]: print Request.blank("http://google.com/index.html")
    GET /index.html HTTP/1.0
    Host: google.com:80

Looks like HTTP to me.

   In [1]: from webob import Request

   In [2]: from paste.proxy import TransparentProxy

   In [3]: print Request.blank("http://google.com").call_application(TransparentProxy())

Yeah the syntax could be less verbose in WebOb, and there was discussion about a nicer client API at one time, but it's fairly trivial to roll your own. Though requests makes short work of common things, I think it actually abstracts some HTTP details more so than WebOb in a way that leaves the user less informed about what's going on in the HTTP, Basic Auth for example. Which makes it it's own protocol, just like WSGI. WSGI in my experience makes light work of implementing HTTP IMO, it's fairly easy to read the part of the HTTP spec you need to handle and then make that work in WSGI, I'm not so sure requests could make that any easier without intervention from the library authors.

I think there's still a place for requests, but I don't see it as becoming the standard way to build HTTP Requests and handle HTTP Responses. I view it more along the lines of a library like mechanize, only nicer. It has it's place.