I definitely think we should have a method like this, I'm just not sure about the naming. To me download_to sounds a lot more like you're trying to download to a file, not just a file object.
We could also just make download accept either a string (the path) or a file-like-object?
I'd like to hear the other developers feelings about this though...

First, let me apologize because I don't understand where the code issue is. The code is running fine on my test bot, and I am not expert at all with travis and coverall. Any suggestion is welcome, so I can try to fix.

Second, yes: I thought about the naming as well. My first idea is to make download() accepting a file object in addition to the path string, but this implied checking for the type (which can be as simple as trying to write() to it and, if failing, assume it's a string and proceed as it is now), but I don't love the parameters where the type can vary significantly.

So I thought about passing a new, optional parameter for the file object, but this means that the current parameter has to be made optional as well, leading to have an API where two parameters are both optional, but one is required, and their use is mutually exclusive. Not a really clear choice, I believe.

So I thought about a separated method. Yes, download_to can definitely be improved; maybe... download_into(writable)? But I cannot come up with a name that is clear and concise at the same time (download_into_file_like_object()).

Closing in favour of #459