UNABLE TO GET IDLE TO RUN

[Peter Otten]

Terry Reedy wrote:

> On 10/26/2015 9:55 AM, Peter Otten wrote:
> 
>> The "bug" or misfeature is that idle automatically adds the working
>> directory to sys.path.
> 
> I am not sure what you mean by 'working directory' here. 

After

$ cd /foo/bar

the working directory is

/foo/bar

> When one runs a
> program with 'python somepath/file.py', python prepends somepath to
> sys.path.

If /foo/bar contains a string.py (for example) module and you run the 
following sequence

$ cd /foo/bar
$ python3 /usr/bin/idle3

/foo/bar/string.py will shade string.py from the standard library. The 
relevant code in idle is

https://hg.python.org/cpython/file/tip/Lib/idlelib/PyShell.py#l1522

"""
    else:
        dir = os.getcwd()
        if dir not in sys.path:
            sys.path.insert(0, dir)
"""

I think this is a misfeature.
 
>> Ideally the editor should see the unaltered path
> 
> I don't know what you mean here.  The editor does not look as sys.path.

idle should see the sys.path as it was before inserting os.getcwd().
 
>> while scripts started from within idle might be allowed to import from
>> the working directory.
> 
> Programs run from the editor are intended to run as much as possible the
> same as if run from a command line.  To do this, IDLE must prepend
> somepath to sys.path the same as python itself does.  As a result, if
> somepath/file.py contains
> 
> import sys
> print(sys.path)
> 
> then when run, sys.path  starts with os.abspath(somepath).

Yes, if inside the shell shown by idle the user types

>>> import string

this should import /foo/bar/string.py rather than the stdlib version.
Different behaviour for "idle the editor" and "idle the shell" is of course 
only possible if both use distinct processes. I don't know idle's 
architecture, so I cannot say if that's already the case or if it would 
require a major rewrite.