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

61–70 of 86 posts

Re: Python Requests: HTTP for Humans

#61

Post by glassx »

DrJokepu wrote: post #43
johns wrote: post #42

Earlier quoted context omitted.

No, no it's not. (Http)WebRequest IS AWFUL. I built RestSharp because HWR is so bad. WebClient is closer to requests, but still horribly awful if you know anything about HTTP. The new System.Net.Http.HttpClient in .NET 4.5 is closer to Requests and not entirely bad, if a little rigid.

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.

I'm not your parent poster but I personally dislike that you have to instantiate a separated Response object, and that you have to fetch a stream, even for tiny responses. In those Python/Ruby frameworks it's just one line. I always end up writing a wrapper just to change it.

And this one is a pet peeve, but I hate that verbose stateful OO idiom where you instantiate an object (with a factory) and then use setters to change properties, instead of setting it all in a single command. I don't know if other .NET HTTP libraries change that, though...

Re: Python Requests: HTTP for Humans

#62

Post by josephturnip »

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.

Re: Python Requests: HTTP for Humans

#63

Post by maxogden »

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…

timelines suggest that requests was inspired by https://github.com/mikeal/request from the land of node

Re: Python Requests: HTTP for Humans

#64

Post by kenneth_reitz »

maxogden wrote: post #63
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…

timelines suggest that requests was inspired by https://github.com/mikeal/request from the land of node

I can assure you that it wasn't :)

Re: Python Requests: HTTP for Humans

#65

Post by kenneth_reitz »

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

Re: Python Requests: HTTP for Humans

#66

Post by johns »

DrJokepu wrote: post #43
johns wrote: post #42

Earlier quoted context omitted.

No, no it's not. (Http)WebRequest IS AWFUL. I built RestSharp because HWR is so bad. WebClient is closer to requests, but still horribly awful if you know anything about HTTP. The new System.Net.Http.HttpClient in .NET 4.5 is closer to Requests and not entirely bad, if a little rigid.

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

Re: Python Requests: HTTP for Humans

#67

Post by Kliment »

bad_user wrote: post #17
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…

In the FAQ it says that support for keep-alive is on the way. I do have a half-baked implementation on urllib2 that I hate. This is really cool.

Is it just me or does the FAQ break the back button?

Re: Python Requests: HTTP for Humans

#68

Post by drgath »

lukeschlather wrote: post #60
efsavage wrote: post #33

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

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.

Re: Python Requests: HTTP for Humans

#69

Post by drgath »

maxogden wrote: post #63
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…

timelines suggest that requests was inspired by https://github.com/mikeal/request from the land of node

Just about every library & language has a Request-like wrapper. It's nothing unique to Node, and certainly nothing unique to client-side JavaScript where native XHR is a nightmare.

Re: Python Requests: HTTP for Humans

#70

Post by simonw »

kenneth_reitz wrote: post #7
megaman821 wrote: post #6

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?

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.

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).
Post reply on HN