How to guard against bugs like this one?

Alf P. Steinbach alfps at start.no
Tue Feb 2 12:20:41 EST 2010


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

+1


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

Hm, not sure about that last.


Cheers,

- Alf



More information about the Python-list mailing list