Where is sys.path set?

[Greg Chapman]

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