Currently (on Windows) we register a set of subcommands in order to display an expanding list of versions of IDLE when users right-click a .py file.

With bpo-27469 (gh-71656)¹, a proper shell extension was added, which means we can now use IContextMenu to implement the menu rather than fixed registry keys. This would allow us to detect all installed versions of IDLE and present them without having to register new keys (i.e. forwards and backwards compatibility).

Another idea: we can also provide extra ("extended") commands when the user holds Shift and right-clicks a file. We could use this to add items to do "-r file.py" with IDLE, which would run the file with IDLE and leave the Shell open.

Would it be possible to allow the user to select whether they'd prefer a nested or flat context menu at install? I believe it went to nested as a result of bpo-23546.

Unless there are a large number of installations (arbitrarily... perhaps 4 or more), the nested menu is a pain for a user like me who wants to open .py files in IDLE more than any other action. (If I may quote the fifth line of The Zen of Python... "Flat is better than nested.") With a little research, it was a fairly easy registry hack to de-nest the context menu.

Still, a lot of people don't like to mess around in the registry, and user choice is usually a good thing. Thoughts?

Even worse: I had both 3.5 and 3.6 installed, and then uninstalled 3.5 when 3.6 was final (I suppose I'm not the only one). Now I have the nested menu with only one item, Open with IDLE 3.6. :-\

Hi Vedran, that seems to now be the default behavior, regardless of previous installs (my 3.6 was a clean install, and it's still nested). Kind of a pain if you want to edit with IDLE frequently.

While we wait for a more integrated solution, the hackish way to restore desired behavior is to run a .bat file containing:

REG DELETE "HKEY_CLASSES_ROOT\Python.File\shell\editwithidle"

Then run a .reg file (also just a text file with altered extension so windows knows what to do with it) with:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Python.File\shell\Edit with IDLE 3.6\command]
@="\"C:\\Program Files\\Python36\\pythonw.exe\" -m idlelib \"%L\" %*"

More user choice here is actually an incredibly huge burden. Managing file associations across a range of versions, many of which can no longer be updated, is hard enough without offering options. Not to mention the extra user interface required.

Personally, I'd rather the options be third party installers or tools. There's nothing stopping someone making an idle "installer" that sets up context menus and default actions however it likes. It would probably break uninstall/upgrade scenarios for the core Python install, but at least it's not a burden on our (very few) volunteers to diagnose, fix and prevent.

If or when the shell extension takes over the context menu (currently blocked on someone volunteering to do the implementation and testing), it may be possible to have registry keys to change the behavior. But I wouldn't count on it being highly configurable - that's not the aim of the main distro.

I'm fine with a single implementation, so long as the implementation is what's best for the majority of users. Not my intent to increase the burden of work.

So, let me ask the question alluded to in my first post: when is a nested menu actually desirable? I would argue that the vast majority of users have one or two versions of Python installed at any given time. And for that number, a flat menu is certainly preferred.

The X.Y version numbering in the context menu introduced as a result of bpo-23546 solves said issue. I'm merely suggesting de-nesting the menu.

The last time I saw collected data on usage (based on Visual Studio users), there was no clear majority of "number of interpreter versions", but 3 was the most common (2 and 4 were roughly equal, 5 and 6 were more popular than 1).

The nesting also makes it considerably simpler for the installer to handle, since there are totally independent components contributing to the file association. This is very difficult to achieve in a reliable way (wrt upgrades/downgrades/uninstalls/repairs/order-of-install/etc.), and having the context menu here is the best balance of reliability, usability and ease of implementation.

Using the shell extension to generate the menu would also work well, as that is part of the launcher and independent of any particular Python installer. It can also automatically un-nest the menu when it's going to be short enough, or show the latest version at the top and nest all others. Ultimately though, implementing that requires somebody's time, and until somebody is motivated enough to do the work, it won't happen.

So your suggestion is valid, it just isn't motivating enough for me to make the change. That doesn't mean someone else can't do it, and from a personal level I will oppose a straight un-nesting (as I'm one of the outliers who has 20+ copies of Python installed on my machines :) ), but I'm totally in favour of a well implemented shell extension to make it more complete and easier to use.

Since you're a developer, I'm sure you need a lot of versions installed so you can check for backwards combatibility (spelling intentional). But until recently, only the most recent IDLE was in the context menu, so I'm guessing your workflow for that checking doesn't depend on the context menu. (I liked the old way, BTW, but I can see how someone might not).

But so long as you're doing it the current way, it remains easily hacked back to the way I like it, so I don't have a whole lot to complain about. Carry on, good sir.

Steve, is this out of date or still something that could be done in the code we control? Would you review and possibly merge a patch is submitted? (I don't know what 'shell extension' means.)

After skimming through @zooba's comments, it seems to me that solving this issue would be added complexity for little benefit.

To make it even more fun, the new context menu in Windows 11 won't show our entries anyway. Apparently people disliked long context menus enough that they all get hidden behind an extra click, and if there is a way to add things back in (which apparently some tools know how to do), we'd end up with the same design of putting them all under a submenu.