RetroSearch Browse

Thu Sep 21 15:05:38 CEST 2006 · https://mail.python.org/pipermail/python-dev/2006-September/068882.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-September/068882.html below:

[Python-Dev] New relative import issue