Python Registry

Introduction

Everything documented here is built in to the core DLL. Any application which uses the Python 1.4/1.5 DLL (either distributed with Pythonwin or not) will get this behaviour.

All registry information is stored under the key:

HKEY_LOCAL_MACHINE\Software\Python\PythonCore\{versionno}.

VersionNo is the Python version number for the release of Python, as found in .the sys.winver attribute. For Python 1.4, this is "1.4.0" - for Python 1.5, this is "1.5.0". The inclusion of this portion should allow different Python versions to peacefully co-exist (except for certain DLL issues, which are a bit hard right now!)

In addition, the installation program creates an entry under

HKEY_LOCAL_MACHINE\Software\Python\PythonCore\CurrentVersion

which contains the version number for the most recently installed version. A program could indirect through this entry to find the registry information for the latest version installed.

PythonPath

The rules for the Python path are:

Note the rules have changed with Python 1.5 to better reflect how Unix treats the PythonPath. More documentation to follow

To take advantage of the registry, and the fact that there are many Python extensions out there, all of which require an entry on the PythonPath, a scheme has been devised that has a number of benefits.

The PythonPath is stored in the PythonPath sub-key (surprise surprise). This PythonPath key may have a value, and it is reserved for the core Python library paths. No "extra" paths are to be placed here. Typically, this will point to the core "lib" and "lib\pc" subdirectories.

PythonPath may have any number of sub-keys. The key name of the sub-key is the name of the application which requires the path, and the value portion is the actual path. The value portion of all subkeys are combined to form the final path.

The order that the subkeys will be used is indeterminate, but the core Path will always be added last. The reason for placing it last is that other applications may provide a module which enhances a core module of the same name. For example, an application may provide a "socket.py", so this will always be found before the standard one.

For example, the PythonPath registry may look like:

PythonPath = "C:\Python\Lib;C:\Python\Lib\PC"

PythonPath\AxtiveX = "C:\Python\ActiveX"

PythonPath\Numeric = "C:\Python\Numeric"

The key names are for informational purposes - only the value portion is relevant.

Registered Modules

There is also the ability to register a module in the registry. Registering a module allows for a single module to be located at any location, not on the Python path. One particularly useful reason for having this is to allow you to expose a module called "xyz" in a DLL which is not named either "xyz.pyd" or "xyz.dll" - it can be in any arbitrary file.

Under the "Modules" sub-key, you can list any number of subkeys. The subkey name is the name of the module, as used by the Python programmer. The value is the full path to the file which implements the module.

If a referenced module can not be located as specified, the normal search mechanism is used.

One limitation to this technique is that the Python "ihooks" capability overrides this. Once any ihooks client has been used (eg, ni, rexec, etc.), this mechanism is not searched.

Other Registry Settings

Some other information stashed in the registry by the installation program is:

Registry Setup

The installation program will set up the registry correctly. There is also a module called "regsetup.py", which can setup and check the registry.