Terry J. Reedy added the comment:
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.
----------
type: behavior -> enhancement
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18766>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
