[Skip Montanaro]
Alright! Now I understand what all the hubbub is about! My eyes have mostly been glazing over trying to follow all this Windows registry/path/ini stuff. MS believes that Python is the application. Those of us writing Python programs view those programs as the applications, not the Python interpreter per se.
Eww -- that's a helpful and insightful way to put it, Skip! Now maybe *I* can understand what the hubbub is about <wink>.
Is there some way that people writing applications in Python can set up registry entries that are specific to their application (e.g. tabnanny.py) instead of only specific to the Python interpreter?
Yes, but they can't get Python to look at those before it's too late. I spent a whole evening a month or two ago just trying to figure out where all the cruft in my Windows sys.path *came* from. This is out-of-the-box; I haven't added anything myself: ['', 'D:\\Python\\win32', 'D:\\Python\\win32\\lib', 'D:\\Python', 'D:\\Python\\Pythonwin', 'D:\\Python\\Lib\\plat-win', 'D:\\Python\\Lib', 'D:\\Python\\DLLs', 'D:\\Python\\Lib\\lib-tk', 'D:\\PYTHON\\DLLs', 'D:\\PYTHON\\lib', 'D:\\PYTHON\\lib\\plat-win', 'D:\\PYTHON\\lib\\lib-tk', 'D:\\PYTHON'] That's bizarre on the face of it, and tracking it all down was draining. I've forgotten the details. I do remember concluding that it was impossible to do what I wanted to do without changing the implementation, though, and nobody on Python-Dev disputed that at the time. In a pragmatic crunch, I wrote the little app I needed to distribute at the time in Perl instead, meaning to come back to this. I haven't had time. IIRC, the ultimate problem wasn't really that Python looked at the registry to get *some* path info, it was a combination of A) It looked at the registry so early that it was impossible to stop it from executing whatever site.py the registry pointed at (well, I could with the -S option -- but then there was no way to get it to do the site.py that was *wanted* instead). B) No way to override what was in the registry; e.g., I was greatly surprised to discover that setting a PYTHONPATH envar didn't override anything, it simply plunked the PYTHONPATH entries into sys.path along with everything else -- and too late to stop anything anyway. In a long msg I haven't yet read all the way thru, Guido at least suggested associating different registry path info with different Python versions. That would address a number of otherwise currently intractable problems. I suspect it still wouldn't help with the problem I was facing, though. That is, I wanted to be able to tell people to run \\dragres01\mrec\reduce\python \\dragres01\mrec\reduce\reduce.py which is just a Windows way of saying "run a Python executable from a shared network location". When they tried that, though, the network Python looked in *their* individual registries for its Python path info, and some of the hackers with mondo customized Python setups on their own machines watched things go down in flames. This certainly can't be a common problem, but it speaks to an unforgiving rigidity in the current approach. There seemed to be nothing I could do to guarantee this would work, short of telling users to edit their registries before running this tool (that's a non-starter on Windows -- editing the registry is dangerous) or putting a customized Python on the network pointing to a bogus registry key (it was faster to write the app in Perl! Perl doesn't *try* to be so infernally helpful <wink>, so doesn't get in the way either). I'm left wondering what purpose putting Python library path info into the Windows registry serves. Is there anyone on Windows who *doesn't* have their Python Lib/ etc as direct subdirectories of the directory containing python.exe? Not that I've seen. Python puts *those* in sys.path too -- but only after it (in the normal case; see my sys.path above) pulls identically redundant paths out of the registry first, or (in the cases we're griping about) pulls irrelevant or downright harmful paths out of the registry first (paths appropriate to the last Python you *installed*, not to the Python that's *running*!). Perhaps all this cruft is needed to support embedded Python, though (something I've never done). Regardless, I expect it would have been enough for me if PYTHONPATH simply worked the way I mistakenly assumed it would (that is, this is sys.path, and that's *it*; feel free to prepend the current directory when initialization is complete, but before then looking at any file not reached from PYTHONPATH is verboten). the-cleverer-the-code-the-more-vital-that-there-be-a-way-to- short-circuit-it-ly y'rs - tim