How to guard against bugs like this one?

Chris Colbert sccolbert at
Tue Feb 2 03:54:04 CET 2010

This is kinda akin to creating your own in a folder where your
compiling and executing c programs and then wondering why your program bugs

On Mon, Feb 1, 2010 at 9:34 PM, kj < at> wrote:

> I just spent about 1-1/2 hours tracking down a bug.
> An innocuous little script, let's call it, only 10 lines
> long, and whose output should have been, at most two lines, was
> quickly dumping tens of megabytes of non-printable characters to
> my screen (aka gobbledygook), and in the process was messing up my
> terminal *royally*.  Here's
> import sys
> import psycopg2
> connection_params = "dbname='%s' user='%s' password='%s'" %
> tuple(sys.argv[1:])
> conn = psycopg2.connect(connection_params)
> cur = conn.cursor()
> cur.execute('SELECT * FROM version;')
> print '\n'.join(x[-1] for x in cur.fetchall())
> (Of course, is pretty useless; I reduced the original,
> more useful, script to this to help me debug it.)
> 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, there is *another* innocuous little script, totally
> unrelated, whose name happens to be  (This second script
> is one I wrote as part of a little Python tutorial I put together
> months ago, and is not much more of a script than;
> it's baby-steps for the absolute beginner.  But apparently, it has
> a killer name!  I had completely forgotten about it.)
> Both scripts live in a directory filled with *hundreds* little
> one-off scripts like the two of them.  I'll call this directory
> myscripts in what follows.
> It turns out that 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/, resulting in *absolute
> mayhem*.
> (This is no mere Python "wart"; this is a suppurating chancre, and
> the fact that it remains unfixed is a neverending source of puzzlement
> for me.)
> How can the average Python programmer guard against this sort of
> time-devouring bug in the future (while remaining a Python programmer)?
> The only solution I can think of is to avoid like the plague the
> basenames of all the 200 or so /usr/lib/pythonX.XX/{,c} files,
> and *pray* that whatever name one chooses for one's script does
> not suddenly pop up in the appropriate /usr/lib/pythonX.XX directory
> of a future release.
> What else can one do?  Let's see, one should put every script in its
> own directory, thereby containing the damage.
> Anything else?
> Any suggestion would be appreciated.
> TIA!
> ~k
> --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Python-list mailing list