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

[Nick Coghlan]

On Thu, Nov 24, 2011 at 11:18 AM, PJ Eby <pje at telecommunity.com> wrote:
> 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.

Oops, meant to reply to this part specifically.

There are two legitimate ways of bundling a dependency inside a
package: either embedding it in your module namespace, or by shipping
a private directory (no __init__.py file) that you place on sys.path.

In both cases, PEP 395 will do the right thing.

In the first case, the parent directory of the embedding package ends
up in sys.path[0] and the embedded copy is accessible as
"package.embedded" (for example). The embedded copy *should* be using
explicit relative imports (if it isn't, it's not safe to embed a copy
as part of your module namespace in the first place). The explicit
relative imports will all refer to the embedded copy as they should,
and everything is fine.

In the second case, the private directory will get placed in
sys.path[0], the embedded copy is accessible at the top-level as
"embedded" and everything is, once again, fine.

You have yet to identify any case where a script will break for a
reason other than reliance on implicit relative imports inside a
package (which are *supposed* to be dead in 3.x, but linger in
__main__ solely due to the way we initialise sys.path[0]). If a script
is going to be legitimately shipped inside a package directory, it
*must* be importable as part of that package namespace, and any script
in Py3k that relies on implicit relative imports fails to qualify.
This is in contrast to 2.x, where the implicit relative import support
in all package submodules let you get away with that kind of approach.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia