import collision between http.py and Python 3's http modules

[miguelgrinberg]

Here is a (granted, obscure) way to reproduce this bug:

1. cd into the werkzeug directory (i.e. where serving.py, http.py, etc. are located).

2. start a Python interpreter

3. type import test. This works for Python 2.x, but in Python 3.x this is what happens:

   (venv34) werkzeug $ python
   Python 3.4.1 (default, Sep  6 2014, 18:06:58) 
   [GCC 4.8.2] on linux
   Type "help", "copyright", "credits" or "license" for more information.
   >>> import test
   Traceback (most recent call last):
     File "/home/miguel/Documents/dev/flask/werkzeug/werkzeug/test.py", line 20, in <module>
       from urllib2 import Request as U2Request
   ImportError: No module named 'urllib2'
   
   During handling of the above exception, another exception occurred:
   
   Traceback (most recent call last):
     File "/home/miguel/Documents/dev/flask/werkzeug/werkzeug/http.py", line 26, in <module>
       from urllib2 import parse_http_list as _parse_list_header
   ImportError: No module named 'urllib2'
   
   During handling of the above exception, another exception occurred:
   
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
     File "/home/miguel/Documents/dev/flask/werkzeug/werkzeug/test.py", line 22, in <module>
       from urllib.request import Request as U2Request
     File "/opt/python3.4/lib/python3.4/urllib/request.py", line 88, in <module>
       import http.client
     File "/home/miguel/Documents/dev/flask/werkzeug/werkzeug/http.py", line 28, in <module>
       from urllib.request import parse_http_list as _parse_list_header
   ImportError: cannot import name 'parse_http_list'
   >>> 
   

The problem is that Python 3's reorg of httplib into http.xxx modules causes an import collision between http.client and werkzeug's http.py, and http.py wins because its directory is in sys.path.

I agree that the example above is pretty obscure and unlike to ever be a problem. A more likely example is when you start an application with the syntax python -m werkzeug.serving -r module:app. In this situation the process starts and then spawns a sub-process for the reloader. The sub-process is going to have the directory where werkzeug.serving is located in the sys.path, so the bug reproduces there as well.

Would you be open to rename http.py? Or do you have a better idea?

[untitaker]

This is almost the same as #461. Adding the werkzeug dir to sys.path happens because of the reloader.