Where is sys.path set?

[Pierre Rouleau]

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?

Here is what I have:


[Shell buffer started: python]
Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information..... print n
....

C:\dev\python
C:\WINDOWS\System32\python23.zip
C:\Python23\lib\site-packages\Pythonwin
C:\Python23\lib\site-packages\win32
C:\Python23\lib\site-packages\win32\lib
C:\Python23\lib\site-packages
c:\python23\DLLs
c:\python23\lib
c:\python23\lib\plat-win
c:\python23\lib\lib-tk
c:\python23
c:\python23\lib\site-packages\Numeric
Thanks

/Pierre

 

[Pierre Rouleau]

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.

---------------------------------------------------------------- */

Thanks a lot Greg, this explains it all!