[issue22121] Start IDLE from icon in a better place.

[Terry J. Reedy]

Terry J. Reedy <tjreedy at udel.edu> added the comment:

Recap and proposal

When editing a named file, Open and Save start in the directory of that file.  Running a file sets the initial working directory of the execution process, which affects imports in the code.

We are here discussing the working directory for the IDLE process.  This affects a. the working directory for interactive code entered without having first run from the editor; b. the start directory for Open and Save in both Shell and any untitled editor windows.

When IDLE is started with command line 'python -m idlelib', its working directory is that of the console.  We agree that IDLE should not change this.  In this case, sys.stdout is not None.  (The exception is when one starts with pythonw, which which is normally useless in the console.)

When IDLE is started Windows Explorer by right clicking a file and selecting 'Edit with IDLE' its working directory is the same as the file.  I propose that IDLE should not change the directory in this case either. In this case, there is at least one filename in sys.args, which IDLE parses anyway.

I initially considered this issue to be about changing the installed Start menu shortcut.  But it was suggested that IDLE code might be better.  Adding a configuration option would require this.  Such code would also not be limited to Windows.  I am currently thinking of something like

if sys.stdout is None and no file in sys.argv:
    start_dir = idleConf(...) #28775, default None?.
    if start_dir is None:
        start_dir = <system-specific default
    try:
        chdir(start_dir)
    except OSError as e:
        <display message>
        try:
            chdir(expanduser('~'))
        except OSError as e:
             <display message -- stay with system default>

This might be somehow coordinated with .idlerc location search.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22121>
_______________________________________