[Sake]
I have Zope and Activestate Python installed together in the same win-xp machine. Everything works fine until I've learned that I can put "sys.setdefaultencoding('cp874')" into sitecustomize.py to accomodate my native language coding. Since I do that, my Zope 2.7.0 service can no longer start. I can start it manually from "runzope.bat", but it never start through the windows system service. A full day investigation reveal that the trouble cause by the missing of the '<SOFTWARE_HOME>\lib\python' in the system environment's "PYTHONPATH". The "runzope.bat" set that up before then execution of "Zope.Startup.run.py", hence it run fine. But "zopeservice.py" rely on the "<SOFTWARE_HOME>\bin\Lib\site-packages\sitecustomize.py" to set up the correct "PYTHONPATH". Here is the code inside Zope's sitecustomize.py
""" Add Zope packages in Windows binary distro to sys.path automagically """ import sys import os try: sp = __file__ except: sp = None if sp: dn = os.path.dirname swhome = os.path.join(dn(dn(dn(dn(sp)))), 'lib', 'python') if os.path.exists(swhome): sys.path.insert(0, swhome)
Unluckily, this sitecustomize.py is now masked with my sitecustomize.py inside Activestate's site-package directory, which actually get loaded by Zope via the Python registry load path (HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\PythonPath) instead of the expected one.
It's actually a different bug: Python normally never looks at the value of the PythonPath registry key, and that's not why your sitecustomize.py is found first. That's actually a side effect of ActiveState installing win32all: if you look *under* HKLM\Software\Python\PythonCore\2.3\PythonPath, you'll find subkeys Pythonwin, win32, and win32com. It's actually the win32com subkey that puts your ActiveState Python's lib\site-packages into sys.path. It's then a bug in Zope that it lets that dirty trick hide its own lib\site-packages: Zope ships with its own Python, and *intends* to insulate you completely (in both directions) from whatever other Python(s) you may happen to have installed on the machine. So when that bug gets fixed, your sitecustomize.py will never get executed. BTW, sys.setdefaultencoding() is almost never a good solution; working with Unicode instead usually is.