There is also an addon for Requests that lets you make OAuth requests: https://github.com/maraujop/requests-oauth-hook
Python Requests: HTTP for Humans
51–60 of 86 posts
Re: Python Requests: HTTP for Humans
#52Earlier quoted context omitted.
Here's the new one I'm working on: https://github.com/tarcieri/http httparty does a few of the same tricks, but I still find its API a bit obtrusive. At least it automatically parses JSON! (my library does this too, if an appropriate library is loaded) In addition to a humane interface, it will soon be backed by a Ragel-generated HTTP parser: https://github.com/tarcieri/http/tree/master/parser
Looks very promising. I see it currently uses Net::HTTP under the hood - do you plan to keep it that way, like Httparty and Faraday, or are you going to do away with Net::HTTP altogether? (The comment saying "this is temporary" next to requiring 'net/https' is encouraging... :))
I plan on eliminating Net::HTTP entirely and writing my own client using Carl Lerche's parser for his Picard library which is written in Ragel:
Re: Python Requests: HTTP for Humans
#53Earlier quoted context omitted.
Here's the new one I'm working on: https://github.com/tarcieri/http httparty does a few of the same tricks, but I still find its API a bit obtrusive. At least it automatically parses JSON! (my library does this too, if an appropriate library is loaded) In addition to a humane interface, it will soon be backed by a Ragel-generated HTTP parser: https://github.com/tarcieri/http/tree/master/parser
Did you get to re-use any of Zed Shaw's excellent parser work from Mongrel?
Zed had two parsers: a server parser as part of Mongrel and a client parser as part of RFuzz. I actually used the client parser from RFuzz in my Rev/Cool.io libraries. I talked to Zed about his plans for these, he wanted to do a unified parser that can handle both HTTP requests and responses (since the only difference between the two is the first line) but he never got around to it. Both projects are now unmaintained.
Carl is working on a comprehensive event-driven HTTP (and Websockets) framework for Clojure. I'm just borrowing his parser and re-wrapping it in Ruby. I prefer to use Carl's as he's (at least for now) actively maintaining it, as opposed to using Zed's abandonware.
Re: Python Requests: HTTP for Humans
#54Absolutely my favourite recent development in the Python world. I won't be mistaken if I say that many of us have built half-arse versions of this on top of urllib(2) multiple times in the past. :-) The support for keep-alive is particularly welcome, huge kudos to the author. Question to users of other languages: do equivalents exist for PHP, Perl, C# or Java? Ruby folks rave about restclient, but is there anything e…
For Ruby, there's also Faraday https://github.com/technoweenie/faraday .
Which is used on the Twitter gem for ruby: https://github.com/jnunemaker/twitter/blob/master/twitter.ge...
Re: Python Requests: HTTP for Humans
#55How does this compare (feature wise) to the poster library? Are they about the same? I've used poster some, but not requests... I'll have to try it now. Just curious how it compares to poster.
Re: Python Requests: HTTP for Humans
#56I don't mean to badmouth Requests or Python in general, it certainly looks like an improvement, but can anyone enlighten me as to why an API that wraps an HTTP request with concise methods is #1 on HN, twice? This looks more like a good answer to SO question than "news". This looks like all the other wrapper methods you spend 5 minutes doing, once, when you start a new codebase?
Maybe because doing the same wrappers over and over again, as short as they might be, is boring?
Re: Python Requests: HTTP for Humans
#57Earlier quoted context omitted.
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 :-/
Re: Python Requests: HTTP for Humans
#58How does this compare (feature wise) to the poster library? Are they about the same? I've used poster some, but not requests... I'll have to try it now. Just curious how it compares to poster.
`requests` used `poster` at least in the past (if I recall correctly)
Re: Python Requests: HTTP for Humans
#59Forgive me if I've missed this, but does this library have support for multipart/form-data POSTing? That's a capability in the python library that's sorely missing - especially in 2.X.
yes, it does
Re: Python Requests: HTTP for Humans
#60I don't mean to badmouth Requests or Python in general, it certainly looks like an improvement, but can anyone enlighten me as to why an API that wraps an HTTP request with concise methods is #1 on HN, twice? This looks more like a good answer to SO question than "news". This looks like all the other wrapper methods you spend 5 minutes doing, once, when you start a new codebase?
The philosophy of Python is that those wrapper methods shouldn't be necessary.
I'm glad when language quirks and libraries get linked, it's good for discussion. (And more informative than a good third of the stuff that gets linked.)