Checked the docs, which are in a horrible state (it's in the Language Ref, no wait it's in the Library Ref even though it's a language feature, no wait it's in a PEP, no wait that is out of date and the real documentation has been posted to a mailing list), and found stuff like this:
From Python Docs: The Module Search Path:
"When a module named spam is imported, the interpreter searches for a file named spam.py in the current directory, and then in the list of directories specified by the environment variable PYTHONPATH. This has the same syntax as the shell variable PATH, that is, a list of directory names. When PYTHONPATH is not set, or when the file is not found there, the search continues in an installation-dependent default path; on Unix, this is usually .:/usr/local/lib/python.
"Actually, modules are searched in the list of directories given by the variable sys.path which is initialized from the directory containing the input script (or the current directory), PYTHONPATH and the installation- dependent default."
Well, that's the theory at any rate. Let's test it with actual code:
# cd /tmp/test-py
# mkdir -p snark/snob
# touch snark/__init__.py snark/snob/__init__.py snark/snob/stuff.py
# echo -e '#!/usr/bin/env python2.5\nimport os\nprint(os.getcwd())\nimport snark.snob.stuff\n'> a.py
# chmod +x a.py
# mkdir bin
# cp a.py bin/b.py
What would you expect to happen when this is run? Surely having the module in the current directory means that running either a.py or b.py from . will work, right?
Traceback (most recent call last):
File "./bin/b.py", line 4, in
ImportError: No module named snark.snob.stuff
Nope! And look at that -- according to Python's own system command, the current working directory (as mentioned in their docs) is the same for both scripts!
Explicitly setting PYTHONPATH fixes this:
# PYTHONPATH=. bin/b.py
..but really, shouldn't the docs be a bit less misleading?
And, for that matter, why the hell is the location of the script used instead of the working directory anyways? Either be sane and use the current working directory, or be slightly less sane and check both.
The whole reason for using Python on this project in the first place was to revert to a language and interpreter that is more stable and more professional (in terms of management style) than Ruby, but this kind of crap certainly gives one pause. If thirty minutes with the language turns up something as obviously broken as the module loader, one shudders to think what is going to come up over the course of the project.
Sad days for the Python boys. The interest of Fowler and his crew must have really given Ruby a leg up in terms of quality.