Home Original page

module search path

Peter Hansen peter at engcorp.com
Mon Dec 23 14:55:22 EST 2002 
Jive Dadson wrote:
> 
> Well, I've discovered a little bit more.
> 
> Python was reading the sys.path from the Microsoft Windows "registry".  That surprised me because I would have thought Pythoneers would consider the registry to be the embodiment of Pure Evil (which, by the way, it is).
> 
> I looked in the Python source code, thinking I would just read the algorithm that hunts for modules and all would be revealed.  Well... it's a bit convoluted.  It iterates through a table that's built by another routine somewhere.  Beyond that, who knows?  I quickly decided it would be easier and faster just to experiment by putting module files of the same name but various types and behavior here and there and observing which ones Python dredged up.  But I haven't done that yet.
> 
> However, I am back on the track.  Microsoft Windows 2000 and I have reached an uneasy truce.  It will let me replace my DLL whenever I want to, provided I don't map the drive it's on as a network drive.  That is a workable compromise that makes us both moderately happy.
> 
> Annow for something completely the same.  Back to draining the swamp ...

We use a network installation of Python at work, and as a rule whenever I find
a local Python instance (we do that from time to time, but it usually ends up
causing trouble) I edit the registry entry from "python" to "python.old" and
make sure the PYTHON.BAT file which is needed to find the network install is
in the PATH of the machine in question.

Basically, we have PYTHON.BAT set to this:

@echo off
set pythonhome=n:\apps\python
%pythonhome%\python.exe %1 %2 %3 %4 %5 %6 %7 %8 %9

Then we use a .pth file in the \apps\python folder to point to
another directory on the network where we keep non-standard extensions.

This can cause some trouble in finding the pythoncom22.dll and the
PyWinTypes22.dll, since it appears they are expected in the c:\windows\system
folder if they aren't found elsewhere.  I can't remember whether this problem
occurs only with the use of the win32all extensions or not.  We resolved
it with the use of a sort of proxy module which finds the sys.exec_prefix folder
and loads the DLLs from there instead, but I suspect there are simpler solutions.

The registry *is* evil, and there are slightly less ugly ways around it 
which are probably worth finding.

-Peter
More information about the Python-list mailing list