Guido van Rossum wrote:
Even worse, it means that exceptions.py and site.py can not be found at all except using the normal PYTHONPATH, and putting their path in Spam_path will *not* work.
Why would you want your own exceptions.py and site.py?
I don't. I never change Python library files. I am worried that they won't be found because I don't trust PYTHONPATH.
Oh dear, I think I heard no instead of yes. Are you saying that if someone else installs a Python app on my customer's machine after I do, and sets a registry entry which sayes to use c:/other/path/to/site.py for site.py (as he may very well want to do), then if my Python program depends on getting my copy of site.py from my directory, it will then use the other copy instead and may very well fail?
Again - why would anyone register their own site.py?
I wouldn't, I am worried that someone else will break my installation. Remember that site.py was invented as a site-specific module, although that function moved to sitecustomize.py.
I presume using GetModuleFileName()? Please send me the patch!
Yes, and OK.
JimA's conjecture: It is currently impossible to ship a Python app which can not be damaged by the installation of a second Python app without using a hacked custom binary.
Sounds right. All tricks to make the app unique require using a different registry key, which requires a change to the DLL. However, you can do this without recompiling! The version string is used is embedded in a resource, so you can patch it using some kind of resource editor. Mark Hammond planned it this way!
I don't understand this. Is there documentation? Jim Ahlstrom