This issue is about name completion and not path completion. I have re-reviewed the patch, current code, current behavior, and the fetch_completions doctstring that more or less explains why name completion cannot reliably work given how Idle now works.

I would add to the docstring that even after running the editor file and before running anything else, there can still be problems.  If one adds 'from mod import SomeClass' and types 'SomeClass.', there will be no help.  This patch will not help either. Getting completions for 'sc.', where 'sc' is an instance of SomeClass, without running code, is an even harder problem. There is, in a sense, no substitute for running the code up to the point where name completion is wanted.  Perhaps an explicit Show Completions(Name completion seems fairly common; I wonder how other editors handle it.)

Idle once ran user code in the idle process, which meant that any module ever imported by running any editor buffer would still be in sys.modules. Thus looking for modules in the Idle process sys.modules was more or less guaranteed to work, and would substitute for the user __main__ module (within the Idle process) being cleared by running another editor buffer.

Idle now, without the -N option, runs edited files in a *new* user processes.  The problem for name completion (and calltips, and shell interaction with the old process) is that Idle discards the previous user process.  So running file B discards the information needed for name completion with file A.  A possible solution to this is to keep a user process for each file and not discard information we may want.

I thought of this idea about a month ago because I am sometimes annoyed when running any file discards an interactive shell process I am not really done with.  After running a file, I sometimes retype or rerun code to recreate the bidings I had before running an editor file.  This change would also help this issue and a similar one with calltips.  I plan to make this proposal the subject of another issue.

If I open Idle with Shell and open a new editor window, then, as Phil noted, typing 're.' and waiting brings up a list of re attributes, whereas 'datetime.' does not.  A year ago, 'textwrap.' did not, whereas now it does, thus illustratig the arbitrary nature of current behavior.

Phil's proposal is to make 'datetime.' act like 're.' by importing datetime.  There are two things I do not like about this.  First, if there is no 'import re' in the file, then putting, say, 're.DOTALL' into the file is a bug in that it will be a NameError when the file is run. I might rather make 'import re' work like 'import datetime', that is fail, by not using sys.module as a backup. Second, the import is done in a process that does not belong to the editor, adding a name binding where is does not belong, and will have to be done again when the file is run.

Phil notes that the current workaround it to do the import in the shell (which, as noted, does it in the wrong place) or run the file (which, as noted, deleted the current process).  If there were a separate process for each editor, then either running the process or doing the import would not have the problems listed above.  If we did do an auto import, it would be under the presumption that it would be imported into that particular process in a later run.  We could also think about doing something else, like checking whether 'import xxx' is in the file and either inserting it or at least warning the user to do so.

I would add to the docstring that even after running the editor file and before running anything else, there can still be problems.  If one adds 'from mod import SomeClass' and types 'SomeClass.', there will be no help.  This patch will not help either. Getting completions for 'sc.', where 'sc' is an instance of SomeClass, without running code, is an even harder problem. There is, in a sense, no substitute for running the code up to the point where name completion is wanted.  Perhaps an explicit Show Completions or Cntl-Space should do so.  This would be more feasible with a separate process so it did not have the side effect of killing the existing user process.

Name completion seems fairly common; I wonder how other editors handle it.

---
In my previous post, I suggested that get_entity does too much by copying to namespaces into one, looking up one name, and discarding the new combined namespace.  Looking more, it also occurs to me that the eval is not needed, as eval(name, namespace) is the same as getattr(name, namespace). I believe the following would do what the current get_entity does. it now does.

def get_entity(name):  # should be a standalone utility function
    try:
        ob = __main__.__dict__[name]
    except KeyError:
        try:
            ob = sys.modules[name]
        except KeyError:
           raise NameError('cannot find %s' % name) from None
    return ob

With this version, the patch would amount to adding
           try:
               import name as ob
           except ImportError

before giving up and raising.

I agree that keeping get_entiry separate (as a function, since self is not used) might make testing easier. The same might be reason to pull more code into separate, more easily tested, units.  So lets keep it separate for now.

The real issue is whether the idea of the patch is a good one or not for how Idle currently works.