no way to read uncompressed content as file-like object

According to the documentation, there are three ways to read the content of the response: .text, .content and .raw. The first two consider the transfer encoding and decompress the stream automatically when producing their in-memory result. However, especially for the case that the result is large, there is currently no simple way to get at the decompressed result in the form of a file-like object, e.g. to pass it straight into an XML or Json parser.

From the point of view of a library that aims to make HTTP requests user friendly, why should a user have to care about something as low-level as the compression type of the stream that was internally negotiated between the web server and the library? After all, it’s the library’s “fault” if it defaults to accepting such a stream. In this light, the .raw stream is a bit too raw for my taste.

Maybe a fourth property like .stream might provide a better abstraction level?

[scoder]

I already explained why this is a design bug and not a feature request: the existing API uses the wrong abstraction and leaks negotiation details of the connection into user space that are at the mercy of the remote site, and thus, that the user should not have to care about. That renders the current raw stream reading support hard to use. Essentially, this is a request for fixing a feature that’s broken, not a request for a new feature.

[scoder]

Basically, response.raw is a nice-to-have feature that most users would happily ignore and some power-users could find helpful, whereas a compression-independent response.stream is a feature that most streaming users would want.