[Tutor] when is a generator "smart?"

[eryksun]

On Mon, Jun 3, 2013 at 12:44 AM, Jim Mooney <cybervigilante at gmail.com> wrote:
> On 2 June 2013 20:33, eryksun <eryksun at 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.