levigross

I know... But as you said (and I agreed) :) dependencies add complexity...

I agree with this sentiment and therefore my Response method is also an `io.ReadCloser` (exposing the http.Response.Body io.ReadCloser that Go has to offer).

I agree with you.

I wrote this library because I didn't want to rewrite those functions every time I started on a new project. I put it online because I figured that I would be useful to others as well.

I am not trying to do things in the "Python way". I am trying to bring some of the same flexibility I get when using the Python requests library to Go.

Jerf,

1. Thank you for the feedback

As you have already seen, I submitted my library to /r/golang and have gotten a lot of feedback – from which I modified the constructs (originally the functions returned channels).

I want to write something that is useful to as many people as possible (all while not alienating anyone) and therefore try not to force users (like I originally did) to use the "asynchronous APIs".

I didn't expect this to end up on HN and was going to start a discussion on golang-nuts on the pros and cons of this construct. Based on that, I was going to remove or keep the APIs.

Originally the API was completely asynchronous (every "request" function returned a channel).

I got a lot of feedback that I shouldn't do that, so I moved the asynchronous requests to specific functions e.g GetAsync and made the standard API synchronous.

yes

I am not very good at naming things and figured to just slap a 'g' on requests => grequests.

I figured that I would write the code and decide on a name later...

Jerf,

Thank you for the suggestion. I plan on adding some functionality to make asynchronous APIs friendlier to use (like a `Do` or `Apply` function etc...). But if you don't choose to use the asynchronous APIs everything still functions the same (in fact the asynchronous APIs use the synchronous functions and slap channels on them)

I agree! The README is really sparse right now (I didn't expect so much exposure right). It is just a matter of time before the README has more information.

Thanks – I wrote this library because I like using requests when writing in Python and wanted something similar when writing in Go.

This is true, however with creating applications with Django you are protected against most basic attacks. The ORM uses parameterized queries, all unsafe output is automatically escaped, Protection against CRLF injection within the framework and protection against HTTP response splitting.

The framework isn't fool proof (no one can protect developers from themselves). But I feel that Django does what it needs to do when it comes to protecting its users.