How to guard against bugs like this one?

[Roy Smith]

In article <hk82uv$8kn$1 at reader1.panix.com>, kj <no.email at 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).