How to guard against bugs like this one?
nobody at nowhere.com
Wed Feb 3 17:55:40 CET 2010
On Tue, 02 Feb 2010 10:38:53 -0800, Carl Banks wrote:
>> 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.
> Mostly incorrect. The CWD is in sys.path only for interactive
> sessions, and when started with -c switch. When running scripts, the
> directory where the script is located is used instead, not the
> process's working directory.
Okay, so s/CWD/directory containing __main__ script/, but the general
argument still holds.
> So, no, it isn't anything like dynamic scoping.
That's what it looks like to me. The way that an import name is resolved
depends upon the run-time context in which the import occurs.
>> 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
> It already is that way, chief.
> I think you're misunderstanding what's wrong here; the CWD doesn't
> have anything to do with it. Even if CWD isn't in the path you still
> get the bad behavior kj noted. So now what?
Search for imports first in the directory containing the file performing
This is essentially the situation with gcc; the directory containing the
current file takes precedence over directories specified by -I switches.
If you want to override this, you have to use the -I- switch, which makes
it very unlikely to happen by accident.
More information about the Python-list