Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:   +41 +0.022% 
   unix x64:   +32 +0.004% standard
      stm32:   +32 +0.008% PYBV10
     mimxrt:   +32 +0.009% TEENSY40
        rp2:   +16 +0.002% RPI_PICO_W
       samd:   +24 +0.009% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:   +20 +0.004% VIRT_RV32

It's actually not easy to make a test for this that is robust because the bug relies on a certain ordering of qstrs in the frozen set of qstrs (it needs qstrs beginning with underscore to appear between the first and last items that match the tab completion).

So maybe it's not worth adding a test for? Does the test you added fail prior to the fix in this PR?

I'll test without the fix again; asyncio did include an _attr in the tab completion when I tested it manually with standard Unix build beforehand though.

This test also highlighted an issue in the original version of this commit in that it was also hiding __foo__ style attributes too.

Curiosity - is the code size change different if it's all in one if statement?

CI needs fixing on this.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.56%. Comparing base (c16a4db) to head (09541b7).
Report is 3 commits behind head on master.

@@           Coverage Diff           @@
##           master   #17108   +/-   ##
=======================================
  Coverage   98.56%   98.56%           
=======================================
  Files         169      169           
  Lines       21948    21950    +2     
=======================================
+ Hits        21633    21636    +3     
+ Misses        315      314    -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@dpgeorge I've got a working test now I think should be reliable.

Added I minor change to the repl test support in run-tests.py to allow using ctrl-keys in these tests, can you think of any negative side effects of this?

Added I minor change to the repl test support in run-tests.py to allow using ctrl-keys in these tests, can you think of any negative side effects of this?

I see it's only used for "special" tests, which limits its scope (that's good!). So probably OK.

But, why does it need to run code using paste mode? It seems like it should work just constructing that class normally?

But, why does it need to run code using paste mode? It seems like it should work just constructing that class normally?

When the class code it "typed" into repl via pty the auto-indent throws it off. I could flatten the class in the .py file, but then would still need backspace to de-dent in between each function.

then would still need backspace to de-dent in between each function

The existing test repl_autocomplete.py has backspace in it as a raw byte. You could follow that.

I'm not against adding an escape sequence parser, but if it's easy to work around that, might be better not to add such complexity?

I guess we don't have any tests for paste mode, so maybe worth adding that anyway, using escape sequences?

I've updated / simplified the escape code parser a little in the latest push as suggested earlier.

I guess we don't have any tests for paste mode, so maybe worth adding that anyway, using escape sequences?

I had thought that, I went looking and didn't find any.
I didn't realise backspace and similar codes could just be added (with a hex editor etc) would you prefer that used for this / paste test, rather than the regex based parser?
Would you prefer a separate explicit paste test as well?

Taking a step back... the test I've added here seems to pass even without the fix in both ./run-tests.py cmdline/repl_autocomplete_underscore.py and ./run-tests.py --via-mpy cmdline/repl_autocomplete_underscore.py - is it only when frozen into the build it fails? Assuming that's the case, I guess this test needs to be partly integrated into

I didn't realise backspace and similar codes could just be added (with a hex editor etc) would you prefer that used for this / paste test, rather than the regex based parser?

No, I think what you added here is an improvement, much easier to see what's going on in the test with the escape sequences.

Would you prefer a separate explicit paste test as well?

Yes, that would be nice, but not necessary. Only if you have time.

Taking a step back... the test I've added here seems to pass even without the fix in both ./run-tests.py cmdline/repl_autocomplete_underscore.py and ./run-tests.py --via-mpy cmdline/repl_autocomplete_underscore.py - is it only when frozen into the build it fails?

No, it's tricky. It really depends on what qstrs are frozen and the order they appear in. And the test behaviour may change if/when more scripts are frozen. So I think we should just leave this PR as-is.

CI is failing again...

CI is failing again...

Fixed again; needed dos2unix on the exp files!.
I've added a repl paste test as well.

Thanks for fixing, it looks good now.

And thanks for the paste test, that's also looking good!

Note: doing tab completion on import <tab> will no longer print modules beginning with an underscore, eg _thread. I guess that's unavoidable, and actually correct behaviour.