Hacker News Reader

Comment by megaman821 | Hacker News Reader

This looks so nice. Is there any upcoming support for HTTP caching? I know it is not the easiest thing to do because you will probably need to make several cache backends (file, db, memcached, redis, etc.) to keep everyone happy.

Also I couldn't tell if there is keep-alive support, is there?

View on HN

Keep-alive is 100% supported in the upcoming v0.7.0 release, along with async i/o :)

Caching: I think that will be best be served by a hook/helper module, but we'll see.

Cool! Is there anything I can look at to see how async I/O will work? Does all the async support depend on gevent monkey patching (as requests/async.py would suggest)?

It's unreleased, and therefore completely undocumented at the moment. But here's the API: https://github.com/kennethreitz/requests/issues/98

Mmm async.

Does that also mean that it will have better support for timeouts? I'm not interested in socket timeouts, more in a 'finish this in N seconds or just give up' thing.

For that reason I am using pycurl now for some stuff where I had previously used the requests library. Which has a really really horrible API :-/

The most interesting thing about caching is that you also get support for 304/Etags/Last-Modified - which is amazingly useful for any application that might hit the same URL more than once. I'd vote for that logic in requests core, with caching as a key/value interface (ship an in-memory or file-based default, but make it easy to hook in memcached/redis/etc ala Django).

Reply on news.ycombinator.com