Barry> First, when Python searches for a module to import, only Barry> sys.path is consulted (modulo other import hooks). It doesn't Barry> really treat $PYTHONPATH or the cwd any differently. It does Barry> initialize sys.path from $PYTHONPATH and it does (sometimes) Barry> include a special marker (the empty string) first on sys.path to Barry> indicate the cwd, but once Python's machinery gets going Barry> $PYTHONPATH is ignored.
Thanks for pointing this out. I made the appropriate changes. [skipping a lot of lines ...] Barry> This means that if you install Python from-source, as many Barry> Python developers do through the default cmmi build, and system Barry> administrators do achieve Python builds isolated from critical Barry> system resources, you could break your system Python by Barry> installing incompatible packages into what you thought was an Barry> isolated environment. You mean because the source install of Python installs into /usr/local/lib/python3.1/site-packages in addition to /usr/local? It still does if I recall correctly. Barry> Because it was unlikely upstream Python was going to change Barry> (e.g. To install from source by default into /opt) or that Barry> Debian Python policy was going to change, Doko came up with a Barry> clever compromise of changing the system Python's /usr/local Barry> claim to be dist-packages instead (mirrored to /usr/lib space Barry> for convenience and consistency). This seemed like a perfectly Barry> workable solution, which I still agree with, despite the mild Barry> surprise factor for seasoned non-Debian-versed Python Barry> developers. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iq4g3a0s....@wks.sunoano.org
