Terry J. Reedy added the comment:
IDLE currently completes global names, attributes after ., and filename
segments after / or \ within a string. In the later two cases, a box will pop
up automatically after a user selected time after typing . or /\ and nothing
thereafter. The filename segments are not quoted in the list box.
These completions work within subscripts.
d[a<tab or wait> pops up global name completion box
d['/<tab or wait> pops up filename completion box
Raymond proposes that IDLE complete 'dictionary [string] keys'. To properly
code and test, we need a more complete specification. For instance, "a string
key box should open after an opening quote that follows '[' that follows a dict
expression". Any opening quote should work, just as for filename completion.
This is similar "a calltip opens after a '(' that follows a callable
expresssion". For calltips, the expression cannot contain a function call,
because calls can take an indeterminant amount of time. If
"expression.find('(') != -1", the calltip is aborted and the same should be
true here. Also, calltips.get_entity(expression) should be reused to get the
dict object. (test_calltips should but does not test that 'f()(' is ignored
and get_entity not called. The same should be true for "f()['".)
Nice (?) but not necessary: delayed auto-popup after typing "d[<open quote>".
This seems that it would be more difficult than the current auto popups. And
see the following.
This proposal conflicts with filename completion for subscripts. When one is
accessing an existing value, one would want key completion. If one is
assigning a value to a new filename key, one would want filename completion.
The simplest solution I can think of is to not auto pop up key completion but
to require <tab> before typing (/\) and waiting.
Lastly, should the string keys be quoted in the box?
| long key |
| short key |
or
|'long key' |
|'short key'|
?
Selecting key objects by their representation is tempting, but it is
conceptually different from completing names. Objects may have one canonical
representation, but many possible representations. So clicking on a list
(which currently does not work) or using movement keys is more sensible than
typing chars that have to match one of many possibilities. String keys would
have to be quoted.
So I would only consider this as a separate issue, depending on a fix for
clicks. It should only be accessed by <tab> immediately after '[', and I might
want to disable selection by character matching.
Even then, I would be dubious. I grepped idlelib for "\w\[". A majority of
subscripts are names, handled by current name completion or not (if the names
are local, which they often are). The rest are either list indexes and slices
involving literal ints or string keys, which this proposal would handle for
accessible dicts. I am pretty sure there are no keys other than names and
strings.
But the sparsity of use cases is my problem even with this proposal. Calltips
are useful because there are many globally accessible callables, including
builtins and imports. But other than class __dicts__, there are few globally
accessible dicts, except perhaps in toy beginner code. Raymond, have I missed
something?
The idlelib grep had 763 hits and I believe more that half are for dicts. But
they may all be locals or self attributes. I would love to be able, for
instance, to type "local_dict['<tab>" and fill in 'background', but that will
not work.
----------
stage: test needed -> patch review
versions: +Python 3.6, Python 3.7 -Python 3.4
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue21261>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
