"buffering" arg support is checked on every call to `ConnectionCls.getresponse()` in HTTPConnectionPool

On Python 3.5 with urllib3 1.15, I just hit the issue discussed in https://github.com/kennethreitz/requests/issues/1289#issuecomment-31294851 where urllib3 is checking for buffering parameter support first, and then falling back to calling getresponse() without any arguments, creating a misleading stack trace when the latter call fails.

Thanks to https://github.com/shazow/urllib3/commit/7fa026c37a5326dcaf97cb9c66ecd15df9c1a194 more recent versions of urllib3 won’t show the confusing chained traceback when a connection fails.

However, it’s also the case that on every current Python version except Python 2.7, the first call will always fail (and even on Python 2.7 it’s relying on an undocumented parameter, so not all Python implementations will support it).

This problem could be eliminated by checking for the relevant signature information once at import time rather than on every call to getresponse:

def _request_response_buffering():
    try:
        names = HTTPConnection.getresponse.im_func.func_code.co_varnames
    except AttributeError:
        return False # Either Python 3 or not CPython
    return "buffering" in names

if _request_response_buffering():
    def _getresponse(conn):
        return conn.getresponse(buffering=True)
else:
    _getresponse = HTTPConnection.getresponse

And then calling _getreponse(conn) instead of conn.getresponse()

If such an approach would be acceptable, then I’d be happy to create a PR for it.

[Lukasa]

I’m open to that, but I should warn you now: there’s plans afoot to remove the use of httplib altogether, so such a patch will have a shortish useful lifetime (less than 6 months I’d hope). It’s up to you whether that makes it worthwhile to you: if it does, I’m certainly happy to review and merge it.

[sethmlarson]

This problem is removed in v2.0 after dropping Python 2.7, going to close this issue.