While working on porting wsgi_intercept to Python 3 I came across a recursion issue with http.client.HTTPSConnection. The following is an lesser extraction of the traceback:


Traceback (most recent call last):
  File ".../wsgi_intercept/test/test_httplib.py", line 28, in test_success
    http = self.make_one(self.domain)
  File ".../wsgi_intercept/test/test_httplib.py", line 40, in make_one
    return http.client.HTTPSConnection(*args)
  File ".../lib/python3.2/http/client.py", line 1075, in __init__
    source_address)
  ...
  File ".../lib/python3.2/http/client.py", line 1075, in __init__
    source_address)
  File ".../lib/python3.2/http/client.py", line 1074, in __init__
    super(HTTPSConnection, self).__init__(host, port, strict, timeout,
RuntimeError: maximum recursion depth exceeded while calling a Python object

Some background information is necessary to explain what is happening here. One, this is a traceback from a test method (make_one) which makes and https connection. Two, wsgi_intercept has overridden http.client.HTTPSConnection with a class that subclasses HTTPSConnection and overrides a few methonds. For more general information, see the PyPI page (http://pypi.python.org/pypi/wsgi_intercept). 

After the wsgi_intercept behavior is invoked the __mro__ of http.client.HTTPSConnection becomes: (<class 'wsgi_intercept.WSGI_HTTPSConnection'>, <class 'http.client.HTTPSConnection'>, <class 'http.client.HTTPConnection'>, <class 'object'>). Because of this we end up recursively running the __init__.

Possible solutions:

1) Fix the issue in http/client.py:1074 by replacing "super(HTTPSConnection, self)" with "super()", which if I'm not mistaken is the recommended usage of super in Python 3.
2) Fix the issue in the wsgi_intercept package.

I was successful with both approaches, but applying the second fix would make the maintenance of wsgi_intercept slightly harder because of the code duplication and round-about-way of calling its parent classes.