I have Python and hence IDLE 3.8, 3.9, 3.10, and 3.11 installed.  When I right click a .py file, and then on "Edit with IDLE >" the sub-menu only has '3.11.0a4' listed.  This negates the purpose of having a submenu.

I did some search of previous issues and see a) that I have had more than one version listed before, but b) there have been previous issues with some missing.  I don't know if #27603 has any relevance.

I discovered this when investigating the report at
https://stackoverflow.com/questions/70931009/cant-open-py-files-in-idle-on-desktop-with-python-3-10-2
For that, clicking on the submenu worked for 3.9 but not after upgrading to 3.10. Clicking for me opened the file, but there was only one choice.

Check your settings in the registry.

In "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts" there should be a ".py" key, but not necessarily. It should have an "OpenWithList" subkey that contains an "MRUList" value (most recently used list). The value should be a sequence of letters, each of which should be a value name in the key. If the launcher was last used to open a ".py" file, the first letter in the list should be a value with the data "py.exe".

Ideally there should also be a subkey named "UserChoice" that contains a "ProgId" (programmatic identifier) value with the data "Python.File". This sets the "Python.File" ProgID as the locked-in user choice for ".py" files. In the GUI, you can set this in the open-with dialog by selecting "always use this app to open .py files". The selected app should be "Python", with an icon that contains the Python logo and a rocket (the launcher).

If ".py" isn't the locked-in user choice, the shell API will use the most recent user selection in the open-with menu. If there's no user selection, the default association is calculated from "HKCR\.py", which is a merged view of "[HKCU|HKLM]\Software\Classes\.py". The default value of "HKCR\.py" sets the default file association. Ideally it should be "Python.File".

"HKCR\Python.File" is a merged view of "[HKCU|HKLM]\Software\Classes\Python.File". For the merged view, if a value name is defined in the same subkey of HKCU and HKLM, the view prefers the HKCU value. There should be a subkey named "shell\editwithidle\shell". It should define one or more subkeys named "edit3*", such as "edit310". Each should contain a "MUIVerb" value that sets the command description in the "open-with" menu. There should also be a "command" subkey that contains the template command as its default value, e.g. ""C:\Program Files\Python310\pythonw.exe" -m idlelib "%L" %*".

The registry settings should be correctly set by the installer.  The bug is that they are not.  I don't touch the registry, and the last 3 versions are less than 2 weeks old.

I wonder if you've managed to install the launcher a second time? If the second one is for current user but the first is for local machine, the Open With entries may not be being merged.

In theory, the installer is supposed to detect a previous launcher and match its setting, but the default did change recently, so maybe the detection is not working.

Not sure when I'll get a chance to check it out, so if someone else wants to check and confirm that would be helpful.

> the Open With entries may not be being merged.

That would probably be a bug in the Windows shell API. The HKCU and HKLM subkeys of "Software\Classes\Python.File\Shell\editwithidle\shell" are merged in the HKCR view. The same key path can exist in both hives, for which the view contains the union, with precedence for HKCU.

For example, with "Software\Classes\spam":

    import winreg

    hkm = winreg.CreateKey(winreg.HKEY_LOCAL_MACHINE, r'Software\Classes\spam')
    winreg.SetValueEx(hkm, 'eggs', 0, winreg.REG_SZ, 'hklm')
    winreg.SetValueEx(hkm, 'baz', 0, winreg.REG_SZ, 'hklm')

    hku = winreg.CreateKey(winreg.HKEY_CURRENT_USER, r'Software\Classes\spam')
    winreg.SetValueEx(hku, 'eggs', 0, winreg.REG_SZ, 'hkcu')
    winreg.SetValueEx(hku, 'bam', 0, winreg.REG_SZ, 'hkcu')

    hkr = winreg.OpenKey(winreg.HKEY_CLASSES_ROOT, 'spam')

    >>> winreg.EnumValue(hkr, 0)
    ('bam', 'hkcu', 1)
    >>> winreg.EnumValue(hkr, 1)
    ('baz', 'hklm', 1)
    >>> winreg.EnumValue(hkr, 2)
    ('eggs', 'hkcu', 1)

    >>> winreg.EnumValue(hkr, 3)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    OSError: [WinError 259] No more data is available

True. I guess we need to dig a little deeper to find a cause here. Any 
other ideas?