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 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.
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.
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.
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.
This is an Über Failure if I have ever seen one. They detected the breech on July 19th but didn't think to check to see if anything was amiss?!? I think that OS companies and browsers must come down hard on compromised certificate authorities. A ZERO tolerance policy should be enforced resulting in a permanent BAN if your private keys are compromised!
I don't mean to praise wall street but Mark Cuban made his initial cash from stock options the same things the people on wall street trade. So he knows very well what businesses they are in.. They made him rich!