On Mon, Jun 3, 2013 at 12:44 AM, Jim Mooney <cybervigila...@gmail.com> wrote: > On 2 June 2013 20:33, eryksun <eryk...@gmail.com> wrote: > >> >> The base sys.path configured in the registry already has lib-tk: >> >> C:\>reg query hklm\software\python\pythoncore\2.7\pythonpath >> >> HKEY_LOCAL_MACHINE\software\python\pythoncore\2.7\pythonpath >> (Default) REG_SZ >> C:\Python27\Lib;C:\Python27\DLLs;C:\Python27\Lib\lib-tk > > Using Python 2.7 on Windows 7 > > pythonpath turned out to not be in pythoncore, so I was baffled at the > source of the original problem. Then I searched the registry for > pythonpath and it was in an entry for an IDE I had just installed, > didn't like, and uninstalled, but it didn't clean up the registry (a > lot of programs do that). Only its pythonpath was for 3.3, explaining > the trouble, since installing was the Last thing I did. I forgot that > the counter to the Law of Unintended Consequences is "What did I do > last?"
I looked into PC/getpathp.c. The value of PythonPath shown above is only a fallback for when Python is embedded. Otherwise the interpreter can determine sys.prefix from the exe path, and substitute it for the dots in the following hard-coded path: .\DLLs;.\lib;.\lib\plat-win;.\lib\lib-tk However, if PythonPath has subkeys, it always adds the default value of each subkey to sys.path. I created a subkey to test this, but otherwise I haven't used this feature. As to the problem you describe, I'm mystified. Registry settings (except environment variables) won't bleed over between Python installations or across application settings in the registry. That was probably just a private PYTHONPATH setting of the IDE, used for starting the interpreter as a subprocess. _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor