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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4