1

Previously, I had Python 3.7.4 installed & working great on Win10. Then, a 3rd party installer (unbeknownst to me) installed Python 2.7...which completely hosed my Python environment (ugh). After removing Python 2.7 and running a repair-reinstall of Python 3.7.4, it's mostly back up and running - except for the ability to drag and drop onto .py files.

Per Drag and drop onto Python script in Windows Explorer and Python Drag-and-drop broken, I've tried:

regedit:

HKCR\.py=Python.File (when I first checked, it was set to py_auto_file, so I did have to change this)
HKCR\Python.File\shell\open\command="C:\Users\xxx\AppData\Local\Programs\Python\Python37-32\python.exe" "%1"
HKCR\Python.File\shellex\DropHandler= I've tried {60254CA5-953B-11CF-8C96-00AA00B8708C}, {86C86720-42A0-1069-A2E8-08002B30309D}, and {BEA218D2-6950-497B-9434-61683EC065FE}

With the above changes, I was able to get Python to launch when dragging-and-dropping onto .py files, but sys.argv does not contain the filename (only argv[0] is set, not argv[1]). Obviously I'm restarting Windows Explorer between each test. I've spent the past several hours searching & reading, but everything I've found pretty much contains some variation of the 3 changes above.

Any ideas why argv[1] would not be set when launching Python by dragging a file onto a .py script?

J23
  • 3,061
  • 6
  • 41
  • 52
  • Begin by inspecting "Python.File" specifically in "HKCU\Software\Classes" and "HKLM\Software\Classes". (Never modify keys via "HKCR".) Ensure that the default value for "shellex\DropHandler" is "{BEA218D2-6950-497B-9434-61683EC065FE}", if defined. Next repair your installation, and ensure the options are selected to install the launcher (py.exe) and associate it with scripts. The latter sets the launcher as the "Python.File\shell\open\command". – Eryk Sun Oct 04 '19 at 23:20
  • Finally, make this progid your user choice in the Windows shell, which has it control the right-click actions and drop handler. To do this, right click a .py file and select "open with" -> "choose another app". Select the Python icon with a rocket on it and the option to "always use this app to open .py files". – Eryk Sun Oct 04 '19 at 23:23
  • In case you're curious or need to verify the drop-handler setting, you can inspect "HKCR\CLSID\{BEA218D2-6950-497B-9434-61683EC065FE}\InprocServer32". This is the shell-extension DLL that gets loaded into a process that's hosting the Windows shell (e.g. explorer.exe). For a 64-bit system, it should be a path to "pyshellext.amd64.dll". – Eryk Sun Oct 04 '19 at 23:30
  • Thanks so much for ur replies. HKCU: Has no Python.File. HKLM does, & is set to {BEA..}. I've done multiple repairs since setting {BEA..} - altho repair-installs don't offer any installer options, I've also tried doing 'modify' reinstalls, where the launcher option is enabled & cannot be disabled. Regarding progid, Py files were already associated with python, but I went ahead & set Open With default app. The behavior remains the same: it opens py files with Python, but argv[1] is not set. I also verified the CLSID is indeed set to C:\Windows\pyshellext.amd64.dll. The issue remains :/ – J23 Oct 05 '19 at 07:46
  • 1
    What is your "HKLM\Software\Classes\Python.File\shell\open\command"? If the launcher is installed for all users, it should be `"%SystemRoot%\py.exe" "%1" %*`, where `SystemRoot` is usually "C:\Windows". Sometimes "%1" is replaced with "%L" (ages ago they used to behave differently, but they're equivalent now). `%*` is for the command line arguments. Before changing it manually, try to repair the "Python Launcher" installation. That should fix the command, if it's wrong, using the installed path of the launcher. – Eryk Sun Oct 05 '19 at 09:22
  • Yesssss - that's it!! The command had "%1," but was somehow missing %*. When I added that...it fixed it! Note again that doing repair installations did NOT actually fix it (for some reason). Thanks so much - if you'd like to post this as an answer, I'll go ahead & accept it :D – J23 Oct 06 '19 at 20:10
  • 1
    Before writing that I did confirm that repairing the "Python Launcher" installation fixed the open command. Note that the launcher installation is separate from the Python installation in the list of installed programs. – Eryk Sun Oct 06 '19 at 20:41
  • You're absolutely right. Now I feel double-dumb. I kept repairing the Python installation, not the Python Launcher, because I had my add/remove list sorted by date & the date for Python was much more recent than Python Launcher, which was several screens down...and I didn't assume it would put two separate entries. And also, the Python install dialog had a "py launcher" checkbox, which made it seem even more like they were integrated. Kinda poor UI, but I also should've followed your tips more precisely. – J23 Oct 07 '19 at 06:20
  • Do you want to post a solution so I can accept it? – J23 Mar 05 '20 at 20:56
  • Alright then, gave it 5 weeks - gonna go ahead & post my exact steps as an answer, for the sake of other readers :) – J23 Apr 09 '20 at 17:39

2 Answers2

0

I managed to solve this by:

  • Do a repair-reinstall of Python 3
  • Do a repair-reinstall of Python Launcher
  • Create HKCU\Software\Classes\Python.File\shellex\DropHandler, with default={BEA218D2-6950-497B-9434-61683EC065FE}
  • Modify HKLM\Software\Classes\Python.File\shell\open\command, to set default="C:\Users\my_user_name\AppData\Local\Programs\Python\Python37-32\python.exe" "%1" %*
J23
  • 3,061
  • 6
  • 41
  • 52
  • 2
    By not using the py.exe launcher in Python.File, you've lost the ability to support shebangs in scripts, which supports multiple Python installations and in particular supports running a script with a particular virtual environment. – Eryk Sun Apr 09 '20 at 17:53
0

Drag and drop did not work here too, because I had accidentally selected a new standard opening program via:

rightclick on a .py file -> open with -> [select any program] -> check the box "use as standard"

in Windows Explorer for .py files.

This killed the drag and drop feature - and also the option "edit with IDLE" is no longer visible in the context menu (this missing entry is a hint for this very user mistake)

Probably you had tried the "use as standard" checkbox as well, to repair your broken python installation.

To get back drag and drop and standard behavior:

A) delete the registry key "openwith" in

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.py

B) reinstall python (or repair the installation)

Background

The "openwith" registry key is only created by the explorer once you set a new standard program. This key is overriding any system defaults from the other registry keys in HKLM and HKCU.

Even if you manually set the "openwith" key to your python.exe (via right click, ... ) windows will just alter the command at the "openwith" key to point to the python.exe - but the DropHandler will still not be applied, because the ShellEx Key is missing in this registry "folder".

And no: I have not yet found this solution anywhere. A search for ".py" in the registry pointed towards this registry key and fiddling with it solved the problem in the end.

If anyone from the python installer reads this: maybe offer the option to delete this key during the installation - to recover properly from any mis-setting.

Red
  • 144
  • 1
  • 7