Allow download_file to return non-raw socket response

[safijari]

Hi,

So, I'm unsure yet if this is actually an issue, but here goes. I'm kinda new to working with HTTP requests and downloading stuff etc. I was trying to figure out how to download large files in a "somewhat-non-blocking" fashion so that I can have a progress bar and I stumbled onto this page (http://www.python-requests.org/en/latest/user/quickstart/?highlight=iter_content). I was able to do what I needed by using the raw response example given, but the page suggests that using Response.iter_content on the "not-raw" response is better (I imagine it does error checking but I'm not sure).

The download_file function returns a raw, but I changed my local copy of client.py so that it doesn't and I can use the iter_content method for downloading files. Would it make sense to add an option to the function so that it can return either? Also, what are the advantages for using iter_content?

Thanks.

[tals]

Hmm. The major difference (aside from the different interface) is that requests (well, urllib3) will decode the returned data. That is actually important in case the data is compressed. I'll look into fixing this without breaking the existing contract.

The other advantage to using this is that it's a bit more convenient, but that's about it. iter_content() itself is rather thin :)

[tals]

Fixed in 1.2.4

[safijari]

Okay, I hope the change doesn't break it for someone reading in data differently. In my local code, I had added another argument to the function called returnraw set to true by default so that raw is returned if the argument is not given. If changed to false, it would give the behavior I was looking for.

[tals]

I prefer to keep the code simple. All these options make the API unusable :)

[safijari]

Okee. Thanks :)