import confused by contents of working directory

[Jon]

It appears that (windows) python searches in the current working
directory before looking in the local site-packages directory, or that
'.' comes first in sys.path? The problem arises when I made the mistake
of running a test program from the same directory where I built and
installed my package. Python uses the package from the current
directory, which misses the pyd files, instead of the site-packages
package which has them installed.

Would somebody please explain how to know what is going on when an
import statement is ambiguous? If the interpreter has several choices
about what to import then which one is chosen? I apologise if this is
FAQ, but it seems that if I say "import mymodule" and the interpreter
finds more than one option for mymodule it could raise an Exception
asking "which one do you want??" instead of silently picking up the
first thing it finds?

This would be perhaps a major change - but I expect "import" to go look
in the python installation and would look for a command like "load" to
go looking for specific filenames or find things that are hanging
around in the current working directory. Is there any plan for a
statement like:

"from future import PleaseDontJustGuessWhatToImport" ?

Thanks in advance for any useful advice, perhaps I am just missing the
out on the "right way to do it"? It is normal to remove '.' from
sys.path at the start of a script?

Jon

-------------------------------------
Some examples of my confusion are outlined below. I use Numeric only
because I assume they are doing a proper installation. I had thought
for a long time that I had this problem because I was screwing up with
distutils or .pth files etc etc.

c:\> mkdir import

c:\> cd import

c:\import> python -c "import Numeric; print 'OK!'"
OK!

c:\import> echo raise Exception("Not OK! Local py file") > Numeric.py

c:\import> python -c "import Numeric;print 'OK!'"
Traceback (most recent call last):
File "<string>", line 1, in ?
File "Numeric.py", line 1, in ?
raise Exception("Not OK! Local py file")
Exception: Not OK! Local py file

c:\import> del Numeric.py

c:\import> mkdir Numeric

c:\import> python -c "import Numeric; print 'OK!'"
OK!

c:\import> echo raise Exception("Not OK! Local version") >
Numeric\__init__.py

c:\import> python -c "import Numeric;print 'OK!'"
Traceback (most recent call last):
File "<string>", line 1, in ?
File "Numeric\__init__.py", line 1, in ?
raise Exception("Not OK! Local version")
Exception: Not OK! Local version

c:\import> del Numeric\__init__.py

c:\import>python -c "import Numeric;print 'OK!'"
Traceback (most recent call last):
File "<string>", line 1, in ?
File "c:\python24\lib\site-packages\PIL\__init__.py", line 1, in ?
#
Exception: Not OK! Local version

[authors note] What??? This was imported from Numeric\__init__.pyc

c:\import> del Numeric\__init__.pyc

c:\import> python -c "import Numeric;print 'OK!'"
OK!

The the actual example is more like this:

c:\ImageD11> python setup.py build --compiler=mingw32 install
....
c:\ImageD11>c:\python24\scripts\ImageD11_gui.py
....
ImportError: can't import name closest

c:\ImageD11> cd ..

c:\> c:\python24\scripts\ImageD11_gui.py
....and the gui runs!! ...

Given that the script resides in $python\scripts I sort of expect it to
avoid tripping over some local and irrelevant file.

 

[Fredrik Lundh]

Would somebody please explain how to know what is going on when an
import statement is ambiguous?

there is no ambiguity: python searches through a list of directories, in a given
order.

the list is stored in the sys.path list, which you can inspect and modify freely.

also see the section "The Module Search Path" in the Modules chapter in the
tutorial:

http://pytut.infogami.com/node8.html

If the interpreter has several choices about what to import then which one is
chosen?

the first one on the path.

</F>

 

[greg]

It appears that (windows) python searches in the current working
directory before looking in the local site-packages directory, or that
'.' comes first in sys.path?

Unless it behaves very differently on Windows from
everything else, this isn't quite true. The current
directory is only put in the path when using the
interpreter interactively. When you do

python somefile.py

the directory containing somefile.py is put at the
beginning of sys.path, not the current directory.
So you'd still have the same problem even if you
weren't cd'ed to the directory containing the test
program.

The moral is not to put your test program in the
same directory as your package files. (Or if you
must, have it delete sys.path[0] before importing
anything.)