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.

Hi,

> wsgi_intercept has overridden http.client.HTTPSConnection with a class that subclasses
> HTTPSConnection and overrides a few methonds.
Do you mean that the module is monkey-patched?

> 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.
Because it’s possible does not mean it’s liked :)  Some of us still dislike that hack.

Sure does. But that's the point of the package.

Why is this super usage without arguments considered a hack?

>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue13771>
> _______________________________________

super without arguments literally relies on a compiler hack.

Could you provide a minimal code sample that demonstrates the problem? I'm having a hard time seeing why the http.client code is buggy.

My guess is Michael was doing something like

>>> class Monkey(http.client.HTTPSConnection):
...     pass
... 
>>> http.client.HTTPSConnection = Monkey
>>> http.client.HTTPSConnection("bugs.python.org")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/http/client.py", line 1210, in __init__
    source_address)
  [. . .]
  File "/usr/lib/python3.5/http/client.py", line 1210, in __init__
    source_address)
  File "/usr/lib/python3.5/http/client.py", line 1209, in __init__
    super(HTTPSConnection, self).__init__(host, port, timeout,
RecursionError: maximum recursion depth exceeded while calling a Python object

Looking at <https://github.com/cdent/wsgi-intercept/commit/d70dfa9>, I think this problem has been overcome by also overriding __init__(). IMO Python shouldn’t go very far out of its way to support monkey patching, and in this case the workaround was disliked by Eric. Given these two facts and no apparent interest since, I think we should close this.