In article <hk82uv$8k...@reader1.panix.com>, kj <no.em...@please.post> wrote:
> Through a *lot* of trial an error I finally discovered that the > root cause of the problem was the fact that, in the same directory > as buggy.py, there is *another* innocuous little script, totally > unrelated, whose name happens to be numbers.py. > [...] > It turns out that buggy.py imports psycopg2, as you can see, and > apparently psycopg2 (or something imported by psycopg2) tries to > import some standard Python module called numbers; instead it ends > up importing the innocent myscript/numbers.py, resulting in *absolute > mayhem*. I feel your pain, but this is not a Python problem, per-se. The general pattern is: 1) You have something which refers to a resource by name. 2) There is a sequence of places which are searched for this name. 3) The search finds the wrong one because another resource by the same name appears earlier in the search path. I've gotten bitten like this by shells finding the wrong executable (in $PATH). By dynamic loaders finding the wrong library (in $LD_LIBRARY_PATH). By C compilers finding the wrong #include file. And so on. This is just Python's import finding the wrong module in your $PYTHON_PATH. The solution is the same in all cases. You either have to refer to resources by some absolute name, or you need to make sure you set up your search paths correctly and know what's in them. In your case, one possible solution be to make sure "." (or "") isn't in sys.path (although that might cause other issues). -- http://mail.python.org/mailman/listinfo/python-list
