Generic response object?

[daa]

Considering possible different client adapters implementation, for example for curio or trio, and their different API regarding response, I thought that it will be useful to pass to callback not raw response from underlying library but some generic adapted version representing common interface. Not so long ago I've read an article where similar ideas are investigated and different http libraries were considered - https://snarky.ca/looking-for-commonality-among-http-request-apis/ . It shows that in simple cases where response body is fully consumed before processing it is possible to define the same interface for all libraries, however when response body is streamed requests, asyncio and twisted use different approaches which can't be reduced to one, at least without introducing much inconvenience for usual library users. What do you think of it?

[ppslim]

An FYI. Oddly, my visit today is of the same theme and a recurring problem I have.

My initial problem originates in the dispatch. I have to assume I have no internet access, cannot compile code, expect almost no libraries to be available and cannot assume the OS / python version (though 2.7 is minimum for other reasons).n Add to this, the platform optionally uses Kerberos, so I may require SPNEGO auth for my API requests.

i.e. I must near enough assume I can only use pure python. The system must have curl though (a pre-req, but not pycurl). So my attempts have been to write a requests adaptor to use in place of the urllib3 driven one (which also means I can selectively use my adaptor in specific session objects).

The difficulty is not the adaptor (at least not the dispatch), but in the response. This needs several files and may limit my response options. However, like is indicated in this ticket, the response may be in part or fully consumed before I can get that low.

One thing I am currently considering is the use of BufferedFile from Paramiko, or even BufferedPipe (my use of curl may be suited to a separate thread, so I can enforce request timeout (though curl offers its own, it's not as granular as requests)).
http://docs.paramiko.org/en/2.4/api/file.html
http://docs.paramiko.org/en/2.4/api/buffered_pipe.html

I still feel like I am using a sledge hammer to crack a nut. I do need session support, but using requests just so I can provide a compatible class with the current uplink logic, seems very overkill.

The need for a response interface in uplink is critical. I can significantly simplify my client if this were the case. My client could simply allow curl to honour redirects and enforce strong SSL/TLS requirements and even use the cookie jar functions curl has (random files at session creation, reused throughout).

The interface could essentially be one that provides absolute minimal support needed to work. Response code, body, headers. Mimic the requests response object, raising NotImplimented were not possible. For extra simplicity, the default implementation should simply be a proxy object for the standard requests.response object.