On 9/21/06, Giovanni Bajo <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com