[Python-Dev] New relative import issue

[Guido van Rossum]

On 9/21/06, Giovanni Bajo <rasky at develer.com> wrote:
> >> Greg Eqing wrote:
> >> There really shouldn't be
> >> any such thing as sys.path -- the view that any
> >> given module has of the package namespace should
> >> depend only on where it is

> My idea (and interpretation of Greg's statement) is that a module/package
> should be able to live with either relative imports within itself, or fully
> absolute imports. No sys.path *hackery* should ever be necessary to access
> modules in sibling namespaces. Either it's an absolute import, or a relative
> (internal) import. A sibling import is a symptom of wrong design of the
> packages.
>
> This is how I usually design my packages at least. There might be valid use
> cases for doing sys.path hackery, but I have yet to find them.

While I agree with your idea(l), I don't think that's what Greg meant.
He clearly say "sys.path should not exist at all".

I do think it's fair to use sibling imports (using from ..sibling
import module) from inside subpackages of the same package; I couldn't
tell if you were against that or not.

sys.path exists to stitch together the toplevel module/package
namespace from diverse sources.

Import hooks and sys.path hackery exist so that module/package sources
don't have to be restricted to the filesystem (as well as to allow
unbridled experimentation by those so inclined :-).

I think one missing feature is a mechanism whereby you can say "THIS
package (gives top-level package name) lives HERE (gives filesystem
location of package)" without adding the parent of HERE to sys.path
for all module searches. I think Phillip Eby's egg system might
benefit from this.

Another missing feature is a mechanism whereby you can use a
particular file as the main script without adding its directory to the
front of sys.path.

Other missing features have to do with versioning constraints. But
that quickly gets extremely messy.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)