Windows file associations fix
Thank you for the detailed info.
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Python.File\shell only had "Edit with Pythonwin", and didn't have an "open" key. I added that in, along with one for the Python.NoConFile which was also missing "open", and it seems to be working happily now.
Again, many thanks for the replies.
From: Python-list [mailto:python-list-bounces+david.raymond=tomtom.com at python.org] On Behalf Of eryk sun
Sent: Friday, November 09, 2018 6:43 PM
Subject: Re: Windows file associations fix
On 11/9/18, David Raymond <David.Raymond at tomtom.com> wrote:
> And why does the Python installer have a check box for "Associate files with
> Python" if it then promptly proceeds to destroy all those associations?
> Could we maybe get that part of the installer fixed for future versions?
The installer configures the HKCR setting to associate .py[w] files;
however, it doesn't delete a user-choice setting in the shell. You
should be able to restore the user choice to the launcher via the
open-with -> choose another app dialog. Select the Python icon with a
rocket on it (for py.exe; the python.exe icon has no rocket), enable
the option to always use this application, and click ok.
If that doesn't restore the association, you'll have to manually
inspect and modify the settings. The following lists the shell's
cached association for the .py file extension, including the user
choice, if any:
reg query %winkey%\Explorer\FileExts\.py /s
a REG_SZ py.exe
MRUList REG_SZ a
Hash REG_SZ aA7ZxnDmUdM=
ProgId REG_SZ Python.File
Currently I have a UserChoice setting locked in. The permissions and
hash value prevent us from modifying this key, but we can delete it,
in which case the shell reverts to using the cached OpenWith*
associations. Here's a command to delete this key (or use regedit if
you prefer a GUI), where %winkey% was previously defined above:
reg delete %winkey%\Explorer\FileExts\.py\UserChoice
If we instead delete the FileExts\.py key, the shell recomputes the
association from the underlying HKCR settings, where HKCR is a merged
view of [HKLM | HKCU]\Software\Classes.
If that doesn't solve the problem, check the default value of [HKCU |
HKLM]\Software\Classes\.py, and its OpenWithProgIds subkey if defined.
Python's installer associates .py files with the "Python.File" program
If that's set correctly, check [HKCU |
HKLM]\Software\Classes\Python.File to ensure it's set up to use the
py.exe launcher. For example, the following displays the default
"open" command for the local-machine Python.File progid:
reg query HKLM\Software\Classes\Python.File\shell\open\command
(Default) REG_SZ "C:\Windows\py.exe" "%1" %*
"%1" (or sometimes "%L") is the fully-qualified path of the target .py
script, and %* has the command-line arguments, if any.
As a side note, you've probably seen examples that use CMD's assoc and
ftype commands (from NT 4.0, circa 1996). These commands work with
HKLM\Software\Classes, which is fine for classic file associations
configured for all users. However, they do not show or modify HKCU
settings, and they're unaware of updates to how the shell works since
XP/Vista such as HKCR\Applications, HKCR\SystemFileAssociations, and
application capability file associations linked in [HKCU |
> Currently: Windows 7. Attempting to run a .py file opens up the "Open with"
> dialog with a bunch of other programs listed. Clicking browse to manually
> select the new python.exe doesn't add it to the list and won't let me do the
You shouldn't manually associate .py files by browsing for py.exe or
python.exe. If you do this, the system creates an automatic progid
that only includes the "%1" target, without the %* command-line
arguments. Typically this broken progid will be
"HKCU\Software\Classes\py_auto_file". Delete these keys if they exist.