Kenneth has put a lot of work into Requests, and it's really turning into something beautiful.<p>On a side note, Kenneth is a standup guy who helped propel me into the world of open source. I made a few slight documentation updates on Requests as part of my first pull request <i>ever</i>, and he made me feel like my contribution was so important.
I think requests and werkzeug are great, but I'm not entirely sure what problems this proposal addresses.<p>First, it will be extremely hard to get Django to replace a large chunk of it's core with an external library. Not only because they don't rely on an external dependencies, but because there's no obvious benefit.<p>For example, why would you replace the Django test client with something resembling requests? There's no need to go through the entire request process cycle just to test a small chunk of code. It makes them less efficient, less accurate, and more difficult to understand when something goes wrong.<p>Second, things like "cachecore" are not synonymous with "http caching", and are extremely confusing names. I think that "uricore" is a good idea, but it's another non-obvious name. It's not a "core" at all, but rather an improved version of urlparse.<p>I think there are a lot of valuable uses that can come from separating common functionality out so it can be reused in various places, but I dont think Python users are concerned about HTTP not mapping 1:1 with WSGI day-to-day. I can definitely say I'm not, and I'd like to think I have some knowledge as to what matters in [Python] web development.
"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."<p>I agree with the assertion that HTTP is the most common denominator.<p># done from memory<p><pre><code> 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
</code></pre>
Looks like HTTP to me.<p><pre><code> In [1]: from webob import Request
In [2]: from paste.proxy import TransparentProxy
In [3]: print Request.blank("http://google.com").call_application(TransparentProxy())
</code></pre>
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.<p>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.
I don't like the idea of everything using HTTP. I prefer ZMQ.<p>There is a substantial work done to process all the HTTP overhead. In addition to that there is no load-balancing included and it would likely be delegated to a whole new service or machine, when ZMQ could just provide this.<p>Instead of relying on Werkzeug and HTTP, I can use DictShield models, serialized to JSON or Python, and send those across ZMQ sockets. The ZMQ sockets don't time out, like HTTP, they are instead removed when a host goes down. PUB/SUB messaging is possible, round-robin routing. Lots of patterns instantly available.<p>Ease in using HTTP itself is welcome, but I don't want to use it in my infrastructure. It's a band-aid for WSGI instead of a solution.
Thank you Kenneth for your contribution to the Python community. Never met but I've used your code. Keep on focusing on what is "right" for the long term and maybe someday we'll get there!
I don't know much about Python, but how does Request/WSGI solve async/long-polling/WebSockets? It would be a shame if they re-did the HTTP stack without solving these issues.
What does <i>Django could potentially utilize the security features provided by httpcore</i> mean?<p>Would Django have to drop their own Request/Response objects and adopt the Requests/httpcore provided ones? Was there any discussion with the Django core devs at pycon regarding it?
I think this issue stems from the fact that while WSGI was a great concept, it hasn't been fully developed, and hasn't been maintained. We need a better set of abstraction layers for socket and HTTP-based interfaces in Python.<p>And by the way, I love Kenneth's work, especially Requests. We use it in production and it's a joy to build on top of it.
What about Python 3? Other than the async submodule (due to the missing gevent dep), requests already supports Python 3, but Werkzeug does not. Is part of the plan for the combined effort to change this, or will requests lose Python 3 support again? (This seems unlikely, but I thought I better ask.)
At the risk of sounding like a negative-nancy the problem he is fixing is the artificial impedance mismatch that was constructed ON PURPOSE by Ian Bicking when he created WSGI.<p>Composability is one of the most powerful concepts we have. WSGI wasn't mistake-proofing middle-ware by making the protocols different, he was breaking composability that is now being fixed by Kenneth et al.<p>Thank You! But let us not allow these mistakes to be made again.
The idea of proxying ZeroMQ over an HTTP layer is intriguing. I have never used the .*MQ variants, but I understand that request/response is pretty popular. At first glance, HTTP emulation seems like it might make a good, soft introduction to a different paradigm, but I'd love to hear from people who've actually used these libraries/protocols.
Lovely how 5 of the *core projects on github have 200+ followers with 4 of the repos empty. If anything, it shows there's interest in the proposed plan. I'm curious what comes of it!