classification
Title: Wrong import module search order on Windows
Type: behavior Stage:
Components: None Versions: Python 2.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: docs@python Nosy List: brett.cannon, docs@python, kota, ncoghlan
Priority: normal Keywords:

Created on 2011-07-28 09:40 by kota, last changed 2013-01-25 19:20 by brett.cannon. This issue is now closed.

Messages (7)
msg141288 - (view) Author: (kota) Date: 2011-07-28 09:40
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']
msg141445 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2011-07-30 16:07
It's actually the documentation that's slightly wrong in this case. On Windows, there is an additional import mechanism based on the Windows registry that is checked before the ordinary sys.path mechanism. (See http://docs.python.org/library/pkgutil#pkgutil.iter_importers)

The easiest way to check if this is happening is to see which version of the code is executed by "python -m parser". If I'm right, that will execute the local parser.py file on both Linux and Windows.
msg141459 - (view) Author: (kota) Date: 2011-07-31 07:38
Yea, it runs the parser.py that time. And I didn't understand the page you linked me to. Would you mind explaining it a bit?
msg141460 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2011-07-31 08:20
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.
msg141464 - (view) Author: (kota) Date: 2011-07-31 13:13
So there isn't any way to load parser.py via import parser on Windows?
msg141485 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2011-08-01 00:01
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.
msg141489 - (view) Author: (kota) Date: 2011-08-01 06:30
Ok. Time to get those people over at glib to fix up their python script then :)
History
Date User Action Args
2013-01-25 19:20:18brett.cannonsetstatus: open -> closed
resolution: not a bug
2011-08-01 06:30:25kotasetmessages: + msg141489
2011-08-01 00:01:24ncoghlansetmessages: + msg141485
2011-07-31 13:13:16kotasetmessages: + msg141464
components: + None, - Documentation
2011-07-31 08:20:32ncoghlansetnosy: + docs@python
messages: + msg141460

assignee: docs@python
components: + Documentation, - None
2011-07-31 07:38:13kotasetmessages: + msg141459
2011-07-30 16:07:41ncoghlansetmessages: + msg141445
2011-07-29 15:47:40eric.araujosetnosy: + brett.cannon, ncoghlan
2011-07-28 09:40:03kotacreate