Issue 12648: Wrong import module search order on Windows (original) (raw)

There seems to be a wrong import module search order (http://docs.python.org/tutorial/modules.html#the-module-search-path) on Windows. Python seems to be loading the built-in module instead of the python code with the same name as the module in the current directory. This only happens on Windows as I tested on Linux and it loaded the module properly.

Steps to reproduce:

  1. Create a file named parser.py' containing print "test"'
  2. Open a console window to the directory you created the file in and run python2.7 -v' or python -v'
  3. Type `import parser'

On Windows, I get this output: import encodings.cp437 # from c:\Python27\lib\encodings\cp437.py

wrote c:\Python27\lib\encodings\cp437.pyc

import parser # builtin

On Linux, I get this: import parser # from parser.py

wrote parser.pyc

test

`sys.path' on Windows: ['', 'C:\WINDOWS\system32\python27.zip', 'c:\Python27\DLLs', 'c:\Python27\lib', 'c:\Python27\lib\plat-win', 'c:\Python27\lib\lib-tk', 'c:\Python27', 'c:\Python27
\lib\site-packages']

`sys.path' on Linux: ['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PIL', '/usr/lib/pymodules/python2.7/gtk-2.0', '/usr/lib/python2.7/dist-packages/gst-0.10', '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/pymodules/python2.7']

The Windows build actually uses the registry to locate the standard library rather than sys.path. This is by design, but isn't really documented properly.

It means that code on sys.path (even in the current directory) won't shadow standard library modules on Windows.

Due to various arcane details about how it is implemented, the emulation of the main import system that is used to run code with the '-m' switch gets the search order the other way around and hence gives a different answer (the same answer as Linux) in cases like this.

As far as I know, not as a top-level module in an installed version of Python (at least, not without mucking about in the registry).

Shadowing standard library modules is generally a bad idea, and this is one of the reasons.