This is kinda akin to creating your own libc.so in a folder where your compiling and executing c programs and then wondering why your program bugs out....
On Mon, Feb 1, 2010 at 9:34 PM, kj <no.em...@please.post> wrote: > > > I just spent about 1-1/2 hours tracking down a bug. > > An innocuous little script, let's call it buggy.py, 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 buggy.py: > > > > 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, buggy.py 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 buggy.py, there is *another* innocuous little script, totally > unrelated, whose name happens to be numbers.py. (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 hello_world.py; > 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 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*. > > (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/xyz.py{,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 > -- > http://mail.python.org/mailman/listinfo/python-list >
-- http://mail.python.org/mailman/listinfo/python-list