An "Applications\python.exe" progid gets created by browsing for "python.exe" when configuring the file association. For example, it gets created by the Windows shell (Explorer) via "open with" -> "choose another app" -> "look for another app on this PC". The shell has no option in this case to indicate that the filetype is a script that needs command-line arguments via "%*", so the "shell\open\command" template that it assigns is incorrect.

If the user also selects to "always use this app", the shell sets a "UserChoice" key in a key named for the file extension under "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts". The user choice overrides the default association computed via HKCR settings. Applications are not supposed to meddle with the "UserChoice" key. Its contents are doubly protected by the key's security and a hash value.

The shell key for the file extension usually has two other subkeys: "OpenWithList" and "OpenWithProgids". These can also override the HKCR file association. The "OpenWithList" key lists executables that have been used to open the filetype via the "open with" menu, and it also contains an "MRUList" value that sorts the list by order of most recently used. The "OpenWithProgids" key caches progids that are used to open the program. Usually there's just one cached progid. But if there's more than one, in my experience the shell selects the progid that's associated with the first exectuable in the "OpenWithList", by order of the "MRUList" value. In this particular and peculiar case, the current file association follows whichever program was most recently selected in the "open with" list.

> I found this report which fixed the problem: 
> https://stackoverflow.com/questions/15281951

Continuing to use the shell-generated "Applications\python.exe" progid means that you won't have shebang support provided by the py.exe launcher (e.g. for associating scripts with particular virtual environments), the "Edit with IDLE" menu, or the shell-extension drop handler. 

I recommend selecting the installed "Python.File" progid instead. It's the "Python" app with the launcher icon that has a rocket on it. If you use the "open with" menu to select this progid, also select the option to always use the selected app. This sets the shell's "UserChoice" key to lock down the file association.

FYI, never modify the HKCR merged view as suggested by the linked SO answer. Modify the source hive in "HKCU\Software\Classes" or "HKLM\Software\Classes". If you modify HKCR directly, the key(s) that you end up modifying could be in one or the other hive depending on what's already present (e.g. you could modify a value just for the current user, though your intent is to modify it for all users). You should know whether you need to modify system settings, user settings, or both. If you don't know, you need to do more research before proceeding.