(original) (raw)
On Fri, Apr 27, 2012 at 10:39, Christian Tismer <tismer@stackless.com> wrote:
On 27.04.12 02:39, Nick Coghlan wrote:Is there a recommendable way to fix this? I would like to tell people
On Fri, Apr 27, 2012 at 7:30 AM, Christian Tismer<tismer@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.
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.