Where is sys.path set?

[Pierre Rouleau]

Greg Chapman wrote:

> On Sat, 23 Aug 2003 17:00:02 -0400, Pierre Rouleau <prouleau001 at sympatico.ca>
> wrote:
> 
> 
>>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\System32\python23.zip' entry is 
>>inside sys.path.  That file/dir does not exist on the disk.  Could a 
>>failing (crashing) Pythonwin installation caused that?
>>
> 
> 
> 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:
> 

> /* ----------------------------------------------------------------
>    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 "application 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_USER is searched and added first.
>      HKEY_LOCAL_MACHINE 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 "application 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 "application 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
> 

Thanks a lot Greg,  this explains it all!

---
Pierre Rouleau