Add a BAT file to launch IDLE with free-threading support

[Locked-chess-official]

Feature or enhancement

Proposal:

To support the free-threading builds better, add idle3.xt.bat can help user easily to open the code files with IDLE in free-threading builds.
The code in this bat can be similar to the idle.bat.

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

[terryjreedy]

Please explain. I have no idea what you are suggesting or why.

PS. The directory is idlelib, not idlelib3. I fixed the typo.

[terryjreedy]

I routinely make debug free-threading buillds for testing IDLE. Both python -m idlelib and python -m idlelib.idle open IDLE just fine from CommandPrompt. To me, 'open code files with IDLE' means opening them to edit. Free threading has nothing to do with that.

[Locked-chess-official]

Please explain. I have no idea what you are suggesting or why.

PS. The directory is idlelib, not idlelib3. I fixed the typo.

Some schools still choose IDLE to teach to be avoid of that students download the malicious plugins. And you can use idle3.xt.bat to always open the code file by select the opening method. That will be useful if the project is always using free-threading builds.
Finally, the name idle.bat and idle3.xt.bat is similar to python.exe, python3.xt.exe and pythonw.exe and pythonw3.13t.exe.

[terryjreedy]

I don't know what 'select the opening method' actually means. Something about installation? I think school kids should be using the py launcher like everyone else. In any case, regardless of how a binary is selected, I see no need for different .bat files, other than the 'w' variant. @zooba Do you understand what OP is getting at?

PS. There is some extra junk in both idle.bat and idlew.bat that should probably be removed

[Locked-chess-official]

I routinely make debug free-threading buillds for testing IDLE. Both python -m idlelib and python -m idlelib.idle open IDLE just fine from CommandPrompt. To me, 'open code files with IDLE' means opening them to edit. Free threading has nothing to do with that.

No. When you click the 'run module', which builds run the code bases on which interpreter run idlelib. In 3.13, if you change pythonw.exe to pythonw3.13t.exe in the idle.bat , you can clearly see the 'free-threading' at the beginning of the GUI.

[Locked-chess-official]

The idle.bat is only support to run with pythonw.exe, so I think that it is needed to add another bat to support for pythonw3.xt.exe

[terryjreedy]

Idlelib has 3 idle.* files: .py, .pyw, and .bat. The first two and idlelib.__main__ are essentially the same. The .pyw extension is only needed when one runs the file directly, without specifying which binary. Windows then runs the file with the binary associated with .pyw instead of the binary associated with .py. It makes no difference when pythonw is run directly.

The .bat file is hard to use as it is buried within the python installation directory. I have been told that it was once useful when starting idle from within another .bat file, but I don't know if that is actually the case. (If so, one could copy the adjusted code into a wrapping .bat.) For me, it has been superseded by the later added py launcher. In particular, >py -3.14t -m idlelib (or pyw to detach from the console) does what you want.

Another reason I am reluctant to add a file is that it will likely become obsolete if the free-threading build become default. (If I were to add it, I would call it, perhaps, 'idle-t.bat.)

[Locked-chess-official]

Idlelib has 3 idle.* files: .py, .pyw, and .bat. The first two and idlelib.__main__ are essentially the same. The .pyw extension is only needed when one runs the file directly, without specifying which binary. Windows then runs the file with the binary associated with .pyw instead of the binary associated with .py. It makes no difference when pythonw is run directly.

The .bat file is hard to use as it is buried within the python installation directory. I have been told that it was once useful when starting idle from within another .bat file, but I don't know if that is actually the case. (If so, one could copy the adjusted code into a wrapping .bat.) For me, it has been superseded by the later added py launcher. In particular, >py -3.14t -m idlelib (or pyw to detach from the console) does what you want.

Another reason I am reluctant to add a file is that it will likely become obsolete if the free-threading build become default. (If I were to add it, I would call it, perhaps, 'idle-t.bat.)

We should not assume that all those learning python understand computer science. Some non-computer science majors in universities also study it. However, textbooks for non-majors usually do not cover cmd knowledge. In China, such college textbooks currently use IDLE, and there are very few knowledge points. Even dangerous expressions like eval(input()) can be used. Require them to use py -m idlelib to open the IDLE might be beyond of their scope of knowledge.

[picnixz]

If users know about free-threaded builds, I think they also know py -3.14t -m idlelib. If the free-threaded build becomes the default, then this also wouldn't be needed.

I think it will be more confusing for new users to have two possible IDLE launchers where one is for free-threaded and one is for regular build. When should they choose one over the other?

[Locked-chess-official]

If users know about free-threaded builds, I think they also know py -3.14t -m idlelib. If the free-threaded build becomes the default, then this also wouldn't be needed.

I think it will be more confusing for new users to have two possible IDLE launchers where one is for free-threaded and one is for regular build. When should they choose one over the other?

No. In schools, who make .py always open with idle.bat are not students but teachers. If for teachers the right to control which builds is also for teachers. If the project is needed to free-threading builds I think that they are not those non-computer professional students or they spend more time studying so that they know.