Looking for feedback on adding import autocomplete to PyREPL

loic-simon · 2025-10-26T17:08:48.115Z

To make progress on this topic, I prepared a POC with these two ideas:

Tomas Roun:

Allow imports but ask for a confirmation (e.g. first <tab> shows a message, second <tab> imports)

Petr Viktorin:

Perhaps lean into this being a heavier and less secure operation, and bind it to another key? Something like [press F8 to import 'foo']?

Both are a bit hacky, but not too complicated changes:

PR for TAB mode
PR for F8 mode^[1]

And to make it easy for everyone to test, I prepared a WebAssembly interactive demo (totally hijacked from the PEP 810 demo, thanks a lot Pablo for the hard work^[2])!

I personaly find TAB mode more convenient to use (especially with laptops where you must hit a combination of keys to enter F8), but I totally understand the security concern behind it.

the tests are those of TAB mode, I’ll rewrite them when needed ↩︎
It even use their Python build, so lazy imports work here too, but ↩︎

sarahrod · 2025-10-26T18:20:52.338Z

This is a really nice approach tbh. I’ve been playing with the demo and the TAB mode makes sense to me at least.

I agree with you that TAB mode is more practical than F8. Having to remember a special function key for this seems annoying especially on laptops where your hitting Fn+F8 or whatever. The double-tab pattern is way more intuitive and its already a habit for most people anyway.

From what i can tell the original concern was mostly about modules getting imported silently which could be slow or have side effects. With the confirmation step that concern goes away. If someone doesnt want to import they just dont hit tab again.

timhoffm · 2025-10-26T22:22:03.084Z

If safety / unintended usage are a concern, one could also go to a true double-tab operation, i.e. similar to a mouse double-click one would have to hit tab twice in short sequence. Hitting tab multiple times with delay would only show the warning but not trigger the import.

Possible positive side effect: we could leave out the message on immediate double-tab. That way experienced users are not bothered with the warning/notification anbout import.

encukou · 2025-10-27T09:21:07.677Z

Perhaps I’m too experienced, but sometimes hit tab three times quickly without much thought. (1 to complete a common suffix and 2 show the “menu” of non-unique completions. _pyrepl only needs two tabs for this but my shell needs all three.)
I’m not convinced we need “security” here, but if we do, I wouldn’t go with double-tab.

Yeah, F8 was a silly example of “another key”.
Shift+Tab maybe?

pitrou · 2025-10-27T10:26:19.486Z

I brought up the security concern but I also think we should not overdo it, a second TAB is ok.

“True double-tab” as in double-clicking sounds awkward and unexpected to me (does this even exist in other UIs?), and let’s not start with F8, triple-tabbing or other oddities.

loic-simon · 2025-10-28T09:35:25.808Z

All right, thanks all for the feedback! I think we can go with the second TAB then

Before I open a PR, I have a second interrogation: should we make effort to handle modules printing stuff during import gracefully? If you try to autocomplete from this import ^[1] in the demo, you’ll see it goes quite messy, but maybe it is rare enough to not bother with it? (exceptions during import are already handled gracefully)

I suppose we could just temporarily catch stdout/stderr and dump their content properly on new lines before re-painting the prompt (that may be better in a follow-up PR, though?)

or from lazy_import demo ↩︎

loic-simon · 2025-12-04T19:49:17.245Z

For anyone interested, my PR implementing auto-complete for attributes has been open for a month now:

Issue
PR
WebAssembly demo

There’s still plenty of time, but I’d really love to see this land in 3.15!

tomasr8 · 2025-12-28T11:35:05.370Z

Hey Loïc! Sorry for the late reply, I took a pause from cpython for a while I’ll try to review your PR soon. Feel free to ping me if I forget!

loic-simon · 2026-01-02T16:34:44.516Z

Update: @tomasr8 suggested that we can automatically import standard library modules, since

there is no risk of unwanted side-effects^[1]
the import time will always be < a few ms

If anyone think this is not ok, please say so!
Otherwise you can check the new behavior on the WebAssembly demo (with a little hack, please read the note!)

except some easter eggs… ↩︎

pf_moore · 2026-01-02T20:25:25.477Z

Loïc Simon:

there is no risk of unwanted side-effects

Yeah, try “from this import <TAB>” for some “unwanted side effects” (or an easter egg, as you call it in the footnote)

And I notice that “from antigravity import <TAB>” says “No module named antigravity”, which may be true in pyodide, but isn’t true in the normal REPL…

I’m not sure this sort of weirdness is OK, TBH, even if it is rare.

loic-simon · 2026-01-02T20:41:58.677Z

Yes, this and antigravity are the two sidlib modules with side effects I’m aware of! But I cannot see why anyone would want to import something from them: these easter eggs are always explained as import this / import antigravity, which never trigger automatic import.

Paul Moore:

And I notice that “from antigravity import <TAB>” says “No module named antigravity”, which may be true in pyodide, but isn’t true in the normal REPL…

Note that antigravity is not suggested by the REPL (eg. if you type from anti<TAB>), precisely because it is not available the message you’re seeing is the same as if you try from spam import <TAB>.

Paul Moore:

I’m not sure this sort of weirdness is OK, TBH, even if it is rare.

I can understand this position, even if I thing the QOL benefits largely outweight the costs.

One thing I would like to do though is to capture any text printed on module import, display it cleanly below the prompt, and then the prompt agao, avoiding the ugly mess that from this import^[1] currently is. Would that alleviate your concerns by some measure?

or from lazy_demo import… ↩︎

pf_moore · 2026-01-02T21:31:09.884Z

Loïc Simon:

Yes, this and antigravity are the two sidlib modules with side effects I’m aware of! But I cannot see why anyone would want to import something from them

Agreed - I’d be fine with just special-casing those two, to be honest. (In the standard REPL, “from antigravity import …” would open the user’s web browser, and that definitely shouldn’t happen, so special-casing is probably the only good option in practice, just to be safe).

Loïc Simon:

One thing I would like to do though is to capture any text printed on module import, display it cleanly below the prompt, and then the prompt agao, avoiding the ugly mess that from this import currently is. Would that alleviate your concerns by some measure?

If we’re just talking about stdlib modules, having a policy that they cannot have any side effects without some way to disable those side-effects in autocomplete mode^[1] is probably better.

If we’re talking about 3rd party modules, output is the least of my concerns. But this has been discussed already, and if the consensus is that it’s OK, then just because I’m personally still not comfortable with the risks, is no reason to rehash everything yet again.

Where “special case the module in autocomplete” is one such option ↩︎

loic-simon · 2026-01-02T23:33:03.213Z

Paul Moore:

having a policy that they cannot have any side effects without some way to disable those side-effects in autocomplete mode is probably better.

Fine by me! I wrote a small script to try and import all stdlib modules / submodules and ran it (on Windows, masOS and WSL) to check for any side effects: in addition of antigravity and this, I found idlelib.idle and a few __main__ submodules that seem to lack a if __name__ == "__main__"' guard; I’m adding them all to a blacklist.

brettcannon · 2026-01-07T20:18:17.738Z

Loïc Simon:

I’m adding them all to a blacklist.

There will need to be a test if there’s going to be a blocklist to make sure it’s up-to-date.

loic-simon · 2026-01-07T20:38:52.908Z

I’m all for it, but how would you write that? We could try to import all stdlib (sub)modules like my quick script did, but I’m not sure how to detect “side effects” programatically… what I saw manually was some text output (this) and program/tab opening (antigravity, idlelib.idle), do we can / want to detect that in a unit test?

I had the same concern when we hardcoded some submodules in the completer (those that could not be detected by pkgutil, see PR), I tend to think that both situations concern rare edge-cases that are not expected to happen in new code.

mikeshardmind · 2026-01-07T20:45:20.753Z

I would think it’s easier to go about it by maintaining two lists, modules that should be possible to import autocomplete, and modules with known side effects that shouldn’t be, and then have automation around detecting new modules that aren’t on one or the other (ideally, not blocking a PR for something like this), and sticking to only importing the known good rather than any not listed as having sideffects.

brettcannon · 2026-01-07T22:38:02.931Z

Loïc Simon:

I’m all for it, but how would you write that? We could try to import all stdlib (sub)modules like my quick script did, but I’m not sure how to detect “side effects” programatically

If we don’t test for this then we should at least write down guidelines on what to do when adding a new module to the stdlib, including avoiding side-effects upon import, otherwise add the module to the blocklist.

cmaloney · 2026-01-08T04:12:17.065Z

Loïc Simon:

I’m all for it, but how would you write that? We could try to import all stdlib (sub)modules like my quick script did, but I’m not sure how to detect “side effects” programatically… what I saw manually was some text output (this) and program/tab opening (antigravity, idlelib.idle), do we can / want to detect that in a unit test?

Any / arbitrary side effects is hard to test for. Ones which we commonly see such as “Does not print” should be more straightforward to do. There’s at least one test which imports every module to make sure “everything is importable” (cpython/Lib/test/test___all__.py at main · python/cpython · GitHub). There’s also tests that running the interpreter only outputs something specific that is expected.

Combining those should be able to test “There is no unexpected printing in any which autocomplete will list”. There may be some work to handle things like deprecation warnings. I suspect test___all__.py will be a good guide for that.

I don’t know how to make sure nothing opens a UI which I think would also be useful to check… In the test suite there is a gui resource which might help guide but that is more of a manual tag.

loic-simon · 2026-01-10T23:15:09.064Z

Thanks for the pointers! I just added a test leveraging test.test___all__, checking for prints to stdout/stderr, the subprocess.Popen audit event (covers webbrowser.open), and tkinter.Tk creation.

loic-simon · 2026-04-05T19:26:47.886Z

Heads up: the PR has just been merged (thanks, Pablo!), so import auto-completion of module attributes should be available in Tuesday’s alpha!