Oleg Broytmann 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 > > I do not understand this. Can you show an example? Imagine I have > two servers, Linux and FreeBSD, and on Linux python is in /usr/bin, > home is /home/phd, on BSD these are /usr/local/bin and /usr/home/phd. > I have some modules in site-packages and some modules in > $HOME/lib/python. How can I move programs from one server to the > other without rewriting them (how can I not to put full paths to > modules)? I use PYTHONPATH manipulation - its enough to write a shell > script that starts daemons once and use it for many years. How can I > do this without sys.path?!
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. -- Giovanni Bajo _______________________________________________ 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