Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python Requests: HTTP for Humans

python-requests.org

Post reply on HN
Print view View original

71–80 of 86 posts

Re: Python Requests: HTTP for Humans

#71

Post by lukeschlather »

drgath wrote: post #68
lukeschlather wrote: post #60

Earlier quoted context omitted.

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.)

I came here with the same question. Considering I come from PHP & JavaScript where the native APIs are awful, wrapping is a necessary step for sanity. Interesting that Python didn't have this until now.

Python has always had it to some degree, but merging these sorts of things into the core language is what major releases are for. No language is perfect. I think the reason you see this upvoted so much is there are so many Python programmers who want to see this on the roadmap for future versions of Python (and it probably will be.)

Re: Python Requests: HTTP for Humans

#72

Post by nemoniac »

Excellent library but they need to fix this piece of misinformation: "A project that is released as GPL cannot be used in any commercial product without the product itself also being offered as open source."

This is false. A project released as GPL can also be released on another (commercial) license.

Re: Python Requests: HTTP for Humans

#74

Post by burke_holland »

johns wrote: post #66
DrJokepu wrote: post #43

Earlier quoted context omitted.

Just out of curiosity, what's so awful about WebRequest? I've been using it for years for various things and never really had a problem with it.

- It's too low level for quick stuff - It handles HTTP basic auth wrong - It throws an exception, AN EXCEPTION, for any response that isn't 2xx - Async is an ugly mess - In love with streams - Horribly inconsistent across framework profiles - ServicePointManager.Expect100Continue - Inconsistent header handling and restrictions - Terrible cookie API

I think it's fine for simple scenarios (i.e. plain GET), but it breaks down in a hurry and the fact that you have to read out of the response stream is real overhead.

Re: Python Requests: HTTP for Humans

#75

Post by masklinn »

burke_holland wrote: post #74
johns wrote: post #66

Earlier quoted context omitted.

- It's too low level for quick stuff - It handles HTTP basic auth wrong - It throws an exception, AN EXCEPTION, for any response that isn't 2xx - Async is an ugly mess - In love with streams - Horribly inconsistent across framework profiles - ServicePointManager.Expect100Continue - Inconsistent header handling and restrictions - Terrible cookie API

I think it's fine for simple scenarios (i.e. plain GET), but it breaks down in a hurry and the fact that you have to read out of the response stream is real overhead.

> I think it's fine for simple scenarios (i.e. plain GET)

So's python's urllib2, the point of `request` is that as soon as you go even slightly beyond very basic GET and POST, it breaks down quickly in a horrible mess.

Re: Python Requests: HTTP for Humans

#76

Post by kgtm »

draegtun wrote: post #36
old-gregg wrote: post #14

Absolutely 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 Perl, I've mentioned this elsewhere here but Mojo::UserAgent looks quite neat. This time with Mojolicious url - http://mojolicio.us/perldoc/Mojo/UserAgent

Interesting things can happen with M::UA in a single line:

  use Mojo::UserAgent;
  print Mojo::UserAgent->new->get('http://freegeoip.net/json/8.8.8.8')->res->json->{country_name};
Very powerful.

Re: Python Requests: HTTP for Humans

#77

Post by josephturnip »

kenneth_reitz wrote: post #65
josephturnip wrote: post #62

I love Requests, but it would be really nice to have some Python libraries with cert-verified SSL support. I've hacked SSL support on top of urllib2 for my projects at work ( https://github.com/josephturnerjr/urllib2.VerifiedHTTPS ), but it'd be really nice if libraries started prioritizing secure communications as a first-order requirement.

This will be in requests very soon. :)

Then I will be porting my projects over to Requests very soon :)

It's pretty easy to implement, as it already works at the lower (socket) level with the ssl module, it just hasn't made it up the stack into urllib2 (or Requests..yet!).

Re: Python Requests: HTTP for Humans

#78

Post by kenneth_reitz »

nemoniac wrote: post #72

Excellent library but they need to fix this piece of misinformation: "A project that is released as GPL cannot be used in any commercial product without the product itself also being offered as open source." This is false. A project released as GPL can also be released on another (commercial) license.

Yes, it has to also be offered as open source.

Re: Python Requests: HTTP for Humans

#79

Post by draegtun »

kgtm wrote: post #76
draegtun wrote: post #36

Earlier quoted context omitted.

For Perl, I've mentioned this elsewhere here but Mojo::UserAgent looks quite neat. This time with Mojolicious url - http://mojolicio.us/perldoc/Mojo/UserAgent

Interesting things can happen with M::UA in a single line: use Mojo::UserAgent; print Mojo::UserAgent->new->get('http://freegeoip.net/json/8.8.8.8')->res->json->{country_name}; Very powerful.

Indeed. And there are many more nice examples in the cookbook: http://mojolicio.us/perldoc/Mojolicious/Guides/Cookbook#USER...

Also check out the command line interface which allows you todo things like this:

  $ mojo get http://mojolicio.us 'head > title'
ref: http://mojolicio.us/perldoc/Mojolicious/Guides/Cookbook#Comm...

Re: Python Requests: HTTP for Humans

#80

Post by objectified »

Although Requests looks very nice, I've wondered why most people wouldn't simply use pycurl - http://pycurl.sourceforge.net/ ? It's stable and you get all the power that cURL has (which is a lot), and the API is fairly simple - although maybe not as pythonic as the Requests API is.

On a side note: last time I checked urllib2 (which actually drives Requests) could not do SSL requests over a proxy, which gave me the feeling that this implementation still isn't very mature.

Post reply on HN