[Import-SIG] Updated PEP 395 ("Qualified Names for Modules" aka "Implicit Relative Imports Must Die!")

[PJ Eby]

On Wed, Nov 23, 2011 at 6:05 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> No feedback at all on the prospect of changing the way we initialise
> sys.path[0] to respect the package information available on the
> filesystem?
>

I gave you feedback previously: I think guessing based on __init__ files
introduces new breakage potential at a distance for things that didn't
break before.  It'll also guess the wrong location when somebody bundles a
dependency inside their package, and you try to run a script from the
embedded package.

I've tried coming up with other ways to guess the right thing to do, but
fundamentally, they're all just guessing.

What if we instead had something like this:

    import sys
    sys.set_script_module('foo.bar', __name__)

And what it did was, if __name__ is '__main__', and sys.path[0] is pointing
to the parent directory of the script file, then it fixes sys.path[0] to
point to the right parent directory level.  (Sanity checking whether you
can then find the __main__ module using the given module name and the
resulting sys.path[0].)

Is it ugly?  Yes.  But it's *explicit*, and provides One Obvious Way to
make a script that's also a module and will work correctly even if it's
part of a package that's been embedded inside another package.

I think that this or some other form of explicit declaration is needed to
get around __init__ ambiguities that exist in the field today.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/import-sig/attachments/20111123/2d86a4eb/attachment.html>