Where is sys.path set?

Re: Where is sys.path set?



Greg Chapman wrote:
[color=blue]
> On Sat, 23 Aug 2003 17:00:02 -0400, Pierre Rouleau <prouleau001@sy mpatico.ca>
> wrote:
>
>[color=green]
>>I can't remember where/how sys.path is set (aside from the automatically
>>loaded site.py) and i get a strange entry in it. Can anyone remind me
>>where/how to control sys.path on a Win32 machine (i'm running XP on the
>>one where the issue arises).
>>
>>I can't figure out why the 'C:\WINDOWS\Sys tem32\python23. zip' entry is
>>inside sys.path. That file/dir does not exist on the disk. Could a
>>failing (crashing) Pythonwin installation caused that?
>>[/color]
>
>
> The python23.zip entry has to do with the support for loading modules from zip
> files. See http://www.python.org/peps/pep-0273.html (esp. the section headed
> "Booting").
>
> Otherwise, I think the best description of how sys.path is set on windows comes
> from a long comment at the top of PC/getpathp.c from the source code:
>[/color]
[color=blue]
> /* ----------------------------------------------------------------
> PATH RULES FOR WINDOWS:
> This describes how sys.path is formed on Windows. It describes the
> functionality, not the implementation (ie, the order in which these
> are actually fetched is different)
>
> * Python always adds an empty entry at the start, which corresponds
> to the current directory.
>
> * If the PYTHONPATH env. var. exists, it's entries are added next.
>
> * We look in the registry for "applicatio n paths" - that is, sub-keys
> under the main PythonPath registry key. These are added next (the
> order of sub-key processing is undefined).
> HKEY_CURRENT_US ER is searched and added first.
> HKEY_LOCAL_MACH INE is searched and added next.
> (Note that all known installers only use HKLM, so HKCU is typically
> empty)
>
> * We attempt to locate the "Python Home" - if the PYTHONHOME env var
> is set, we believe it. Otherwise, we use the path of our host .EXE's
> to try and locate our "landmark" (lib\\os.py) and deduce our home.
> - If we DO have a Python Home: The relevant sub-directories (Lib,
> plat-win, lib-tk, etc) are based on the Python Home
> - If we DO NOT have a Python Home, the core Python Path is
> loaded from the registry. This is the main PythonPath key,
> and both HKLM and HKCU are combined to form the path)
>
> * Iff - we can not locate the Python Home, have not had a PYTHONPATH
> specified, and can't locate any Registry entries (ie, we have _nothing_
> we can assume is a good path), a default path with relative entries is
> used (eg. .\Lib;.\plat-win, etc)
>
>
> The end result of all this is:
> * When running python.exe, or any other .exe in the main Python directory
> (either an installed version, or directly from the PCbuild directory),
> the core path is deduced, and the core paths in the registry are
> ignored. Other "applicatio n paths" in the registry are always read.
>
> * When Python is hosted in another exe (different directory, embedded via
> COM, etc), the Python Home will not be deduced, so the core path from
> the registry is used. Other "applicatio n paths" in the registry are
> always read.
>
> * If Python can't find its home and there is no registry (eg, frozen
> exe, some very strange installation setup) you get a path with
> some default, but relative, paths.
>
> ---------------------------------------------------------------- */
>
> ---
> Greg Chapman
>[/color]

Thanks a lot Greg, this explains it all!

---
Pierre Rouleau