How to guard against bugs like this one?

[Nobody]

On Tue, 02 Feb 2010 15:00:28 +0000, Grant Edwards wrote:

>>> 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.
> 
> 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.

As it stands, imports are dynamically scoped, when they should be
lexically scoped.

>> 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.
> 
> Searching the current directory by default is the problem.
> Nobody in their right mind has "." in the shell PATH and IMO it
> shouldn't be in Python's import path either.  Even those
> wreckless souls who do put "." in their path put it at the end
> so they don't accidentally override system commands.

Except, what should be happening here is that it should be searching the
directory containing the file performing the import *first*. If foo.py
contains "import bar", and there's a bar.py in the same directory as
foo.py, that's the one it should be using.

The existing behaviour is simply wrong, and there's no excuse for it
("but it's easier to implement" isn't a legitimate argument).

The only situation where the process' CWD should be used is for an import
statement in a non-file source (i.e. stdin or the argument to the -c
switch).