Windows file associations fix

eryk sun eryksun at gmail.com
Fri Nov 9 18:42:48 EST 2018


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:

    set "winkey=HKCU\Software\Microsoft\Windows\CurrentVersion"
    reg query %winkey%\Explorer\FileExts\.py /s

Output:

    HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\
    Explorer\FileExts\.py\OpenWithList
        a    REG_SZ    py.exe
        MRUList    REG_SZ    a

    HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\
    Explorer\FileExts\.py\OpenWithProgids
        Python.File    REG_NONE

    HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\
    Explorer\FileExts\.py\UserChoice
        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
identifier (progid).

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

Output:

    HKEY_LOCAL_MACHINE\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 |
HKLM]\Software\RegisteredApplications.

> 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
> association.

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\Applications\py.exe", or
"HKCU\Software\Classes\Applications\python.exe", or
"HKCU\Software\Classes\py_auto_file". Delete these keys if they exist.



More information about the Python-list mailing list