On 7/18/2011 4:55 PM, Vinay Sajip wrote:

Glenn Linderman <v+python <at> g.nevcal.com> writes:

    Here is a list of py.exe references in my registry:
    HCR\Python.CompiledFile
    HCR\Python.File
    HCR\Python.NoConFile

      [snip]


There shouldn't be so many references, so I suggest you may want to try the
following (after backing up your registry first):

So, then, there must be 2 problems... one in the launcher installer, and the other being whatever happened to my machine.

Can you list the ones there should be?

1. Uninstall all instances of the launcher.

Well, there is only one. But I can certainly remove it, and see what happens.

2. Remove all registry keys for .py, .pyc, .pyo, .pyw, Python.File,
Python.NoConFile, and Python.CompiledFile.

Yes, I can do this.

3. Re-install the launcher (64-bit) using "msiexec /i launchsys.amd64.msi
ALLUSERS=1" (or launcher.amd64.msi if you prefer - the only difference is the
installation directory).

So what I had done was just double click launchsys.msi. Why should there be command line parameters, rather than question/answer dialogs? This is Windows after all. What does the parameter do, that would be different than what double click did?

4. Check that the removed associations have appeared under HKEY_LOCAL_MACHINE,
and that they all point to the launcher installed in the previous step. These
may also appear in HKEY_CLASSES_ROOT if it is aliased to the
HKEY_LOCAL_MACHINE\Software\Classes tree.

I also still don't understand why CMD reports a different command line via its assoc/ftype commands for the Python.File than actually gets used by CMD to launch the .py file.

Found the following at http://zetconsultants.com/blog/?p=36:

Second issue (not really an issue, however something that makes our situation more complicated) is the fact that HKCR is in fact registry symlink and this registry key doesn’t really exists on system. It is merge of two different keys – HKLM\Software\Classes and HKCU\Software\Classes. You probably already guessed (correctly) that this is the way how you can overwrite some settings on per-user basis – HKCU key always wins.

which is useful, but still doesn't explain the variant results from ftype and launching behavior.}

They further say:

You need to create file type using FTYPE first and then associate this TFYPE with executable using ASSOC command. Even though this process is not very simple, you can use it. There is one HUGE disadvantage though and I still don’t understand how is it possible – both FTYPE and ASSOC works only on per-machine level! Therefore you cannot configure per-user associations using these tools!

Currently, there is no way through the UI to change or edit the user-specific file type associations stored in the HKEY_CURRENT_USER\SOFTWARE\Classes registry key. If you want to do this, you have to directly edit the registry or develop your own UI to gain access to this information.

Above you can see official Microsoft statement about this issue.

So maybe the problem is that ftype and assoc report the HLM values, but CMD actually uses the HCU values. This actually would explain what I am seeing, and this is the piece of information I didn't understand that caused my confusion.

So as long as everything is installed for "all users", then there is no confusion! I see I have less than 3 dozen extensions installed in HCU, and over 800 in HLM, so clearly I choose "all users" most of the time. It would be painstaking to see if the 3 dozen were all consistent or not, without writing a program to help.

Clearly the launcher installer should offer the same choices as Python itself for installing for one or all users, rather than defaulting silently to one user. Better, the default should be inherited from the Python installation... if they are all consistent, and if permissions allow the modification of HLM settings.

Regards,

Vinay Sajip

So I can fix my machine, now that I understand what went wrong (delete py.exe entries from HCU, and put them in HLM instead).

Then the other problem I have, is why py.exe launched py 2.6.4 instead of py 3.2.1 when 3.2.1 is newer, and I don't have a #! line. That is probably the defined behavior of the launcher, to prefer 2.x if 3 isn't specified. I'll have to reread the launcher PEP. In my environment, I would much prefer to use 3.x if 2.x isn't specified... so hopefully when I reread the launcher PEP, I'll discover a way to do that. (I recall one can put -3 on the command line, so I could do that in the py.exe ftype commands, but hopefully there is a way to tweak the py.ini to do that.)

Thanks for your response, and help in creating the launcher.