hello,
pep 397 describes a "Python launcher for the Windows platform.
    A Python launcher is a single executable which uses a number of 
    heuristics to locate a Python executable and launch it with a
    specified command line."

Problem: that affects only the "open" file action behavior, and not the "EDIT with idle" file action behavior, and then it is the last installed IDLE who wins.
the problem is not the IDLE changes themselves, but that one version's IDLE can only run the edited script in its version, and ignoring the shebang.

Could the windows installer install a third executable (for ex: pyi.exe)
which launch the correct IDLE according to the shebang line of the edited file?
Or maybe it should be done using "pyw.exe /edit <filepath>"...

Than you for reading this and have a nice day/evening!

To be more exact, (I believe) 'Edit with Idle' runs the equivalent of '<python> -m idlelib -e <file>' where <python> is the current default python (ad <file> is the file right-clicked on).  Idle just goes alone for the ride.  You are proposing more or less that <python> be replaced with 'py'.

The problems with this are that it is still opaque which version of python (and hence Idle) will be run, there is no way to select the version to be run, most people do not use #! on Windows, especially beginners, and some people want to be able to open, edit, and run a file on both 2.x and 3.x (currently most often 2.7 and 3.4).

This same issue has come up on stackoverflow.  To me, a much better solution would be an explicit 'Open with Idle x.y' on the context menu for each version of Idle installed.  This would be explicit and allow version selection.  (I am obviously proposing that the 2.7 and 3.4 installers be tweaked also.)

the "py -m idlelib -e <file>" command failed!
(issue 23610 created)

otherwise, yes, different versions of the "edit with idle" command sounds better.

Sorry.  That has to be "py -3 ... " unless you have configured 'py' to run 3.x, or "py -m idlelib.idle ..." for 2.7.

Terry J. Reedy added the comment:
> Sorry.  That has to be "py -3 ... " unless you have configured 'py' to
run 3.x, or "py -m idlelib.idle ..." for 2.7.
>

Any reason not to add idlelib.__main__ to 2.7? It works the same in either
version, as far as I can tell.

At one time, there would not have been any point.  https://docs.python.org/3/library/__main__.html#module-__main__ contains this sentence "For a package, the same effect can be achieved by including a __main__.py module, the contents of which will be executed when the module is run with -m.", which was new for 3.0.  The .../2/... doc does not as this is a new-in-3.0 feature.  Thus, I am surprised by
C:\Users\Terry>py -m idlelib
C:\Programs\Python27\python.exe: No module named idlelib.__main__; 'idlelib' is a package and cannot be directly executed
AFAIK, 2.7 should not even be looking for .__main__.

After I copied idlelib/__main__.py to my 2.7 install and repeated the command line, Idle tried to start, but imports of submodules failed, subprocess connection failed, and the editor was opened for blank numbered files like 'C:/programs/python27/50343'.  After that, normal ways of starting Idle also failed similarly.  Reinstalling 2.7 (with remnamts of the old idlelib left) did not fix things.  The only way I found to restore Idle was to delete 2.7 idlelib/ completely and run Programs and Features (win 7) repair, which restores a fresh copy that works again.  I tried again with same results, so I am done experimenting.

Perhaps I misunderstand what you meant but "python -m module_name" is a documented Python 2 feature:

https://docs.python.org/2/using/cmdline.html#cmdoption-m

I think the failure to initialize when using -m idlelib after copying over __main__.py from Python 3 is caused by IDLE2's reliance on buggy import behavior fixed by Issue7902.  In any case, applying 556b9bafdee8 from Python 3 seems to fix it.

Sorry, my apologies: I was testing incorrectly. Applying 556b9bafdee8 from Python 3 is not sufficient; there are still some other path import issues with extensions and icon files.  But it shouldn't be hard to track those down and fix them, assuming supporting '-m idlelib' on 2.7 was deemed desirable.

Thanks for the link to where the doc *was* updated for 2.7.  Currently, -m idlelib.idle works, so copying idle.py to __main__.py should make -m idlelib work.  I will try this later, and see if the exact contents of idle.py are needed.  Having '-m idlelib' work uniformly would be nice.

in fact, the idlelib.__main__ file exists in the 3.4 version...
the question is: is it possible to make it exist on older versions?

Liam, your question was answered in the technical sense in my two previous messages.  However, being able to type 'python -m idlelib' instead of 'python -m idlelib.idle' is a separate issue from 'Edit with Idle' on the right context menu.

Steve, is it possible to add "Edit with Idle x.y" on the context menu for each x.y" installed?  Or even "Edit with Idle x.y (nn)"? in case both 32 and 64 bit versions are installed?

It's possible, though personally I wouldn't like it (but I don't use IDLE, so I guess that makes the difference). I'd prefer to be able to list them all under the Open With menu, since that also allows users to easily make any of them the default if that's what they'd like. Unfortunately, to do that we need to start shipping an EXE launcher, probably with a unique name (e.g. idle35-32.exe).

Alternatively, if IDLE provided a selection of installed versions within the program, then it would make sense to always open with the most recent version (or more likely, the most recently installed version, due to how file associations have to be set up when you don't have separate .EXEs).

Currently the 3.5 installer doesn't add any commands for IDLE, so when I fix that I'll include the version information. It may require that the py launcher is also installed, since the launcher owns the file association.

"""to do that we need to start shipping an EXE launcher, probably with a unique name (e.g. idle35-32.exe)."""
nope, the windows packages already include an "idle.bat" launcher next to the "idle.py" and "idle.pyw" files. However, this launcher is (strangely enough) not used in the "edit with idle" command.
Is it, by the way, possible to have that, instead? (you can click on the menu button, OR select an idle)

(uploaded file: dd.bmp)

> I'd prefer to be able to list them all under the Open With menu, 
> since that also allows users to easily make any of them the 
> default if that's what they'd like. Unfortunately, to do that 
> we need to start shipping an EXE launcher, probably with a 
> unique name (e.g. idle35-32.exe).

Can't you just create a ProgID, e.g. IDLE_3.5, that defines the "open" verb, and add this to the OpenWithProgIds subkey for .py and .pyw?

https://msdn.microsoft.com/en-us/library/windows/desktop/hh127445%28v=vs.85%29.aspx

> the windows packages already include an "idle.bat" launcher next 
> to the "idle.py" and "idle.pyw" files. However, this launcher 
> is (strangely enough) not used in the "edit with idle" command.

Why run a batch file instead of directly running the .pyw script via pythonw.exe? A batch file is executed by cmd.exe, which is a console application. 

I believe the batch was included as a convenient way to start IDLE from the command line with the correct version instead of the default system Python. Nowadays idle.pyw should have an explicit shebang and be installed into Scripts, including a Windows .exe wrapper to make it runnable via CreateProcess. This would already be the case if IDLE were bundled in the same way as setuptools and pip, right?

Setting up a progid is my intent, but it will be linked very closely to the executable. Currently it will show up as "pythonw.exe" and not idle.

I didn't try with the batch file, but I'm fairly sure that's failed in the past too. I like the idea of (approximately) using pip to install it though. The generated idle3.5.exe in that case is only going to conflict between the 32/64-bit versions at least.

>Why run a batch file instead of directly running the .pyw script via >pythonw.exe? A batch file is executed by cmd.exe, which is a console >application.
the strange thing is that it exists

Hey Terry, as a first step towards fixing the current 3.5 issue of not having Edit with IDLE at all, is it okay if the "Edit with IDLE" menu launches (approx.) "py -m idlelib.idle %1"? Currently the shortcut menu is part of the launcher - the "Open" item launches "py %1", so they'll be consistent.

An expanded menu like Liam's mockup is possible, but I can't guarantee I'll be able to get to it in time. (It may also be better as something configurable within IDLE anyway - https://msdn.microsoft.com/en-us/library/windows/desktop/hh127424(v=vs.85).aspx describes how it can be done purely through the registry on Win7 and later.)

er... is the fact that py -m <module> ignore <module>'s shebang deliberate?
(using the 3.4.2 version of py.exe)

I believe so. py.exe doesn't provide the -m option, so it has already selected the version by the time that starts running.

Shebangs are really just for launching the file directly. python -m <module> on Linux will also ignore the shebang.

Also, that should be "py -3 -m idlelib.idle %1" so we get the actual latest IDLE from the context menu. (This does not affect the start menu items at all.)

Some people use Windows Explorer as their default means for working with programs and files, including Python via Idle and their own .py files. What some need, as I said previously, is an explicit 'Edit with Idle x.y' for each installed Python.  They need this for the same reason that we add a separate directory to the Start Menu for each version, and not just one Python directory.  If you want me to take this request to pydev, I will, but it seems straightforward to me.

For 3.x, '-m idlelib' is sufficient, '.idle' is not needed (at least from the Windows command line).  I just verified that that 'py -3 -m idlelib path' opens path in a 3.5.0a2 Idle editor.

The fact that installing the experimental -- and broken for Idle -- alpha as non-default changes the behavior of the above incantation illustrates why separate context menu entries are needed, and why the associated command should be 'py -x.y -m idlelib %1'.

(Yes, the only option recognized by py.exe is a version option.  Anything after, like -m, is an option either for the python that py runs or the program that python runs.  '-m module' is equivalent to a .py file, so anything after that is am option for the module being run as a program.)

> If you want me to take this request to pydev, I will, but it seems straightforward to me.

"I'll go get Dad" seems a fairly immature threat and it's really not necessary.

However, (after writing and then deleting a long exposition of the options) the most reliable way of doing this is indeed to install one context menu item per Python install, and I may even be able to handle cascading, at least for 3.5 and later. The one caveat is that if you don't install the launcher you won't see the association at all, and this limitation is necessary to avoid corruption due to parallel installs (granted Python 3.4 and earlier will corrupt the association, but there's nothing we can do about that now).

When I get home tonight I'll update the patch I've been working on and make sure it works as I'm expecting.

Collapsing multiple 'Edit with Idle x.y' entries into one 'Edit with Idle >' + submenu (or 'Edit with Idle 3 >' + submenu) would be fine once practical to do so.

I'll try, but if it's not feasible now I doubt it will become feasible until the next installer revamp. Completely separate items are certainly okay.

I've committed a change that adds a submenu for IDLE almost exactly like Liam's mockup.

Thanks for pushing me on this, I probably wouldn't have worked this hard to get something as robust otherwise :)

thank you for all this hard work.
really.