[Python-Dev] 3.2.1 encoding surprise

[Glenn Linderman]

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 
> <http://support.microsoft.com/kb/257592/en-us> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110718/6deafa19/attachment.html>