The Future of Python HTTP
I think requests and werkzeug are great, but I'm not entirely sure what problems this proposal addresses.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.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.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.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.