On Sat, 18 May 2019, dieter wrote:
Test this by looking at "sys.path" instead:
import sys
sys.path
It is "sys.path" which actually controls the import machinery.
Dieter,
Thank you. I missed this when researching PYTHONPATH. Here's what I get:
sys.path
['', '/home/rshepard/development/bustrac', '/usr/lib/python37.zip',
'/usr/lib/python3.7', '/usr/lib/python3.7/lib-dynload',
'/usr/lib/python3.7/site-packages']
All directories are present, and the one for the current project is the
first one searched.
"sys.path" is typically a sequence of folders. Python's import machinery
will look in those folders for modules/paackages for its (absolute)
imports. Thus, if you use "import XXXX" or "from XXXX import ...", then
one of those folders should contain a module or package named "XXXX".
I understand this. Within ~/development/bustrac as the CWD when I invoke the
test application with the first line:
from classes import model as m
I still see this result:
$ python3 test_act_de.py
Traceback (most recent call last):
File "test_act_de.py", line 1, in <module>
from classes import model as m
ModuleNotFoundError: No module named 'classes'
'classes' is a package (a subdirectory) containing an empty __init__.py, not
a module. 'classes' conains a single module, model.py.
Since the project's root directory is seen by sys.path I don't know why the
import statement keeps failing.
Thanks,
Rich
--
https://mail.python.org/mailman/listinfo/python-list
