How to guard against bugs like this one?

Roel Schroeven rschroev_nospam_ml at
Tue Feb 2 22:38:43 CET 2010

Op 2010-02-02 18:02, Nobody schreef:
> On Tue, 02 Feb 2010 15:00:28 +0000, Grant Edwards wrote:
>>>> 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*.
>>> I feel your pain, but this is not a Python problem, per-se.
>> I think it is.
> I agree.
>> There should be different syntax to import from
>> "standard" places and from "current directory".  Similar to the 
>> difference between "foo.h" and <foo.h> in cpp.
> I don't know if that's necessary. Only supporting the "foo.h" case would
> work fine if Python behaved like gcc, i.e. if the "current directory"
> referred to the directory contain the file performing the import rather
> than in the process' CWD.

That is what I would have expected, it is the way I would have
implemented it, and I don't understand why anyone would think
differently. Yet not everyone seems to agree.

Apparently, contrary to my expectations, Python looks in the directory
containing the currently running script instead. That means that the
behavior of "import foo" depends very much on circumstances not under
control of the module in which that statement appears. Very fragile.
Suggestions to use better names or just poor workarounds, IMO. Of the
same nature are suggestions to limit the amount of scrips/modules in a
directory... my /usr/bin contains no less than 2685 binaries, with 0
problems of name clashes; there is IMO no reason why Python should
restrict itself to any less.

Generally I like the design decisions used in Python, or at least I
understand the reasons; in this case though, I don't see the advantages
of the current approach.

The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
  -- Isaac Asimov

Roel Schroeven

More information about the Python-list mailing list