import problems *newbie*

[mike kreiner]

I am having trouble importing a module I created. I'm running PythonWin
on Windows XP if that helps. I saved my module in a folder called
my_scripts in the site-packages directory. I edited the python path to
include the my_scripts folder (it now reads
C:\Python23\Lib;C:\Python23\DLLs;C:\Python23\Lib\lib-tk;C:\Python23\Lib\site-packages\my_scripts).
When I try to import the module, I get this error:
Traceback (most recent call last):
File "<interactive input>", line 1, in ?
ImportError: No module named PolyDraw

When I select Browse PythonPath from the tools menu, I'm able to locate
my module, PolyDraw.py.

The problem goes away if I open PolyDraw.py from PythonWin, which I'm
assuming is because opening the module makes my_scripts the current
working directory. This is just a quick workaround, but I'd like to
know how to fix the problem. Thanks.

-Mike

 

[F. Petitjean]

Le 13 Jan 2005 21:58:36 -0800, mike kreiner a écrit :

I am having trouble importing a module I created. I'm running PythonWin
on Windows XP if that helps. I saved my module in a folder called
my_scripts in the site-packages directory. I edited the python path to
include the my_scripts folder (it now reads
C:\Python23\Lib;C:\Python23\DLLs;C:\Python23\Lib\lib-tk;C:\Python23\Lib\site-packages\my_scripts).

Not a very godd idea to mess with the python path

When I try to import the module, I get this error:

Traceback (most recent call last):
File "<interactive input>", line 1, in ?
ImportError: No module named PolyDraw

When I select Browse PythonPath from the tools menu, I'm able to locate
my module, PolyDraw.py.

The problem goes away if I open PolyDraw.py from PythonWin, which I'm
assuming is because opening the module makes my_scripts the current
working directory. This is just a quick workaround, but I'd like to
know how to fix the problem. Thanks.

A quick fix is to promote your my_scripts folder to be a python package,
by creating a python module (file) named __init__.py right in the
package directory. The content of __init__.py can be for instance
#!/usr/bin/env python
# -*- coding: Latin-1 -*-
"""
my_scripts package containing miscellaneous modules
PolyDraw
....
"""
__author__ = 'mike kreiner'

To import from this package the syntax is
from my_scripts import PolyDraw

 

[Steve Holden]

Le 13 Jan 2005 21:58:36 -0800, mike kreiner a écrit :


Not a very godd idea to mess with the python path

Furthermore it should not be necessary!
OK, have your modifications to the path worked?

Try adding

import sys
print sys.path

before the import statement to verify what Python is actually using as
the path.

A quick fix is to promote your my_scripts folder to be a python package,
by creating a python module (file) named __init__.py right in the
package directory. The content of __init__.py can be for instance

The __init__.py can actually be completely empty, but surely then you'd
have to import the module by

from my_scripts import PolyDraw

which is a little less convenient. It would be easier (and also easier
than modifying the PYTHONPATH) just to create a .pth file (say
C:\Python23\Lib\site-packages\my.pth) containing the single line

my_scripts

and that should ensure that the directory really *is* on your path.

The *name* of the .pth file is irrelevant, and you can actually have
several lines naming different directories (whose paths can be absolute,
or relative to the directory containing the .pth file).

Obviously you should check that the path's setting is correct using the
technique allowed above.

#!/usr/bin/env python
# -*- coding: Latin-1 -*-
"""
my_scripts package containing miscellaneous modules
PolyDraw
....
"""
__author__ = 'mike kreiner'

To import from this package the syntax is
from my_scripts import PolyDraw

Let's not recommend this as a way around the problem - let's find out
what the problem actually *is* and fix it ;-)

regards
Steve

 

[mike kreiner]

Thanks for your help Steve and F. Petitjean. Sorry for taking so long
to get back, I was away from my lab for a few days.

The path to my directory was not included in the sys.path list. Adding
a my.pth file to the site-packages directory fixed the import problem.
F. Petitjean, I originally edited the PYTHONPATH because "Learning
Python," the O'Reilly book, says to do so. I like your and Steve's
solutions better--editing the PYTHONPATH seems a little unwieldy--but
just to satisfy my curiosity, what are some of the reasons these
methods are preferable?

Steve, as far as finding out the cause of this problem, I muddled
around python and the registry for a while, but nothing jumped out at
me. The only thing I can think of is that I have both Python 2.3 and
2.4 installed, and I'm currently working in 2.3. I thought that
PYTHONPATH was an environment variable, so having two different
versions wouldn't affect it, but I was wondering...should I bother
uninstalling 2.4 to see if the prob gets fixed? Other than that I'm
still something of a newbie, but I'd love to actually help fix this bug
if you can think of anything for me to try (oh joy, my first open
source contribution!). Thanks.

~mike

 

[Grig Gheorghiu]

In my experience (as a tester), it is easier to deal with PYTHONPATH
than to add the my.pth file to the site-packages directory. The main
reason is that I have my custom packages and modules in a directory
tree that I deploy on many clients/servers/platforms/OS versions, some
running different versions of Python. I found that I solve my import
problems by adding one line to .bash_profile, which sets PYTHONPATH to
the parent directory of my custom directory tree. Or, on Windows, I add
an Environment variable, call it PYTHONPATH, and set it to the
necessary directory. The alternative would be to hunt for the
site-packages directory (of which there might be several) on all my
systems.

I guess it's a matter of taste in the end, but I do find the PYTHONPATH
approach more suitable for automation and scripting, particularly when
dealing with a large number of systems.

Grig

 

[Steve Holden]

In my experience (as a tester), it is easier to deal with PYTHONPATH
than to add the my.pth file to the site-packages directory. The main
reason is that I have my custom packages and modules in a directory
tree that I deploy on many clients/servers/platforms/OS versions, some
running different versions of Python. I found that I solve my import
problems by adding one line to .bash_profile, which sets PYTHONPATH to
the parent directory of my custom directory tree. Or, on Windows, I add
an Environment variable, call it PYTHONPATH, and set it to the
necessary directory. The alternative would be to hunt for the
site-packages directory (of which there might be several) on all my
systems.

I guess it's a matter of taste in the end, but I do find the PYTHONPATH
approach more suitable for automation and scripting, particularly when
dealing with a large number of systems.

Grig

In the long term it doesn't really matter: the fact that my suggestion
to use a .pth file worked does leave me still wondering why a PYTHONPATH
setting didn't.

The advantage of using a .pth file *in the site-packages directory* is
that it only applies to the version that picks up that site-packages
directory, while PYTHONPATH applies to any Python you happen to run. In
the case of libraries this will lead to recompilation of the bytecode
(.pyc) files each time a different-version interpreter is used to run
the program.

Unless Skip Montanaro's ideas about directing bytecode files to specific
locations are picked up, it would seem like a good idea to point out the
desirability of using separate copies of Python module sources for
different interpreters.

Anyway Mike, I'm glad you have a reliable solution to your problem.

regards
Steve