[Python-Dev] package imports, sys.path and os.chdir()

Brett Cannon brett at python.org
Fri Apr 27 22:00:48 CEST 2012


On Fri, Apr 27, 2012 at 10:39, Christian Tismer <tismer at stackless.com>wrote:

> On 27.04.12 02:39, Nick Coghlan wrote:
>
>> On Fri, Apr 27, 2012 at 7:30 AM, Christian Tismer<tismer at stackless.com>
>>  wrote:
>>
>>> No big deal and easy to work around, I just would like to understand why.
>>>
>> I don't like it either and want to change it, but I'm also not going
>> to mess with it until the importlib bootstrapping is fully integrated
>> and stable.
>>
>> For the moment, there's a workaround in runpy to ensure at least
>> __main__.__file__ is always absolute (even when using the -m switch).
>> Longer term, I'd like to see __file__ and __path__ entries to be
>> guaranteed to be *always* absolutely, even when they're imported
>> relative to the current working directory.
>>
>>
> Is there a recommendable way to fix this? I would like to tell people
> what to do to make imports reliable. Either I put something into
> the toplevel __init__ code, or I hack something into .pth or sitecustomize,
> and then forget about this.
>
>
No, there isn't.


> But I fear hacking __init__ is the only safe way that works without
> a special python setup, which makes the whole reasoning rather
> useless, because I can _not_ forget about this.... waah ;-)
>

Yeah, to guarantee the semantics you are after you have to grab that ''
entry in sys.path as early as possible and substitute it with the cwd so
that its initial value propagates through the interpreter. Importlib is
already having to jump through some hoops to treat it as '.' and even that
doesn't get you what you want since that will change when the cwd is moved.

I'm personally in favour of changing the insertion of '' to sys.path to
inserting the cwd when the interpreter is launched.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120427/3c557b51/attachment-0001.html>


More information about the Python-Dev mailing list