Erroneous character when reading in a loop

[drepamig]

I'm testing out running the select menu on an unknown depth configuration dictionary like so:

while hasattr(workingLibrary, "keys"):
    print("Available Configurations")
    choices = list(workingLibrary.keys())
    workingLibrary = workingLibrary[choices[cutie.select(choices)]]

After the first loop, it appears as though there is an erroneous keypress (in my case a letter P) detected and waiting in the buffer. When I use the arrows to make the 2nd selection, two key presses are detected/passed and it breaks out of that selection and continues on to the 3rd. This behaviour repeats until I hit the end of the dict. I added the following code to your init.py from Rosetta Code:

def flush_input():
    try:
        import msvcrt
        while msvcrt.kbhit():
            msvcrt.getch()
    except ImportError:
        import sys, termios    #for linux/unix
        termios.tcflush(sys.stdin, termios.TCIOFLUSH)

And call that function immediately before "keypress = readchar.readkey()" and it solves the issue. I've tried to track down the source of the erroneous keypress, but haven't had any luck.

[provinzkraut]

Could you show us some data so that the issue can be recreated?

I think it is more of an issue with readchar.

Should be fixed though if the suggestions from issue #7 get implemented.

[drepamig]

Sure - I was able to duplicate the issue with this code:

import cutie

sampleDict = {
    "a": {"1": {"d": 9, "e": 8}, "2": {"f": 7, "g": 6}, "3": {"h": 5, "i": 4}},
    "b": {"1": {"d": 9, "e": 8}, "2": {"f": 7, "g": 6}, "3": {"h": 5, "i": 4}},
    "c": {"1": {"d": 9, "e": 8}, "2": {"f": 7, "g": 6}, "3": {"h": 5, "i": 4}},
}

workingDict = sampleDict

while hasattr(workingDict, "keys"):
    print("Available Configurations")
    choices = list(workingDict.keys())
    workingDict = workingDict[choices[cutie.select(choices)]]

Run it and make your first selection then try to make a 2nd selection. You'll see it rapidly loop through the dict and crash with an index out of range error.

If I add the flush_input() function referenced in my first post to fire immediately before keypress = readchar.readkey(), the menu behaves as expected.

[provinzkraut]

I can't reproduce the described behaviour.. Are you sure this is exactly what you're doing in your code?

[Kamik423]

I also cannot reproduce the issue. What version of python and cutie are you using? You mentioned an init.py. There was an __init__.py that has been removed in version 0.1.0.

[drepamig]

Update: I completely removed cutie using PIP, and reinstalled it using pip install git+https://github.com/Kamik423/cutie.git. This corrected the __init__.py to be cutie.py, but the issue remains. I also tried it in a new and barebone Anaconda environment with no improvement.

Thanks for helping me with this! I'm using Anaconda with Python 3.7. I'm using the latest cutie available from PyPI (cutie-0.2.1), which I removed and reinstalled at the start of the recording. I also made sure readchar was the latest available as well (not shown in the recording). I still notice that in my site-packages directory, the cutie folder still contains a __init__.py after reinstallation. Is my whole issue because I'm using an out of date version?

I recorded an example of the behavior and posted it below. I included the onscreen keyboard so you can see my inputs when the issue arises.

The contents of getkey_error.py are the same as the GIST posted before:

import cutie

sampleDict = {
    "a": {"1": {"d": 9, "e": 8}, "2": {"f": 7, "g": 6}, "3": {"h": 5, "i": 4}},
    "b": {"1": {"d": 9, "e": 8}, "2": {"f": 7, "g": 6}, "3": {"h": 5, "i": 4}},
    "c": {"1": {"d": 9, "e": 8}, "2": {"f": 7, "g": 6}, "3": {"h": 5, "i": 4}},
}

workingDict = sampleDict

while hasattr(workingDict, "keys"):
    print("Available Configurations")
    choices = list(workingDict.keys())
    workingDict = workingDict[choices[cutie.select(choices)]]

[Kamik423]

I still cannot reproduce the issue.

HOWEVER, I think it should be fixed in a new branch. Could you manually download the version from there and try if the issue still occurs?

Depending on your setup you might have to:

# Uninstall cutie
pip3 uninstall cutie
# Link the branch version
# (In the downloaded directory)
pip3 install -e .

And then try to reproduce.

Of course you can afterwards revert back to the release version with

pip3 uninstall cutie
pip3 install cutie

Thank you for your help!

[drepamig]

Ok, so I have a bit more information. I tried the new branch and it's improved. The extra key in the buffer is still there, but it doesn't immediately cause cutie to continue to the next menu, so that's an improvement. Since you can't reproduce this, I tried rebooting into safe mode and testing (to eliminate any other programs that may be interacting) and still had the same issue. I then installed cutie on another computer with Anaconda3 and tried the test - WORKS FINE! But that just made my issue more confusing. I then installed a completely separate instance of python (WinPython 3.7 zero), ran the test in there and it also WORKS FINE! Now I have no idea what would be causing it in my primary python installation. Whatever the problem in my installation is, flushing the buffer fixes it...

tldr: Something isn't working right in my python installation but your fix improved the experience and makes it usable. Cutie works fine for me in a clean (new) python installation. I have to fix my python.

Sorry for wasting your time and I appreciate the help!

[Kamik423]

Thank you for the huge amount of effort you are putting into this!

You are saying, that it "improves" the situation. Is there any way you are still noticing it or is it (for all intents and purposes) fixed? The extra key should just get dropped now.

If there is any chance people could still be experiencing this I'd rather play it save and try to catch the mysterious character.

[drepamig]

The changes you made have caused the extra key to be ignored, but you still have to "get past" it. It's a little clunky to explain, so here is a recording of it in action - notice how I have to hit the arrow twice on the 2nd and 3rd menu prompt. It doesn't affect the selection like it used to, but it's still there.

The other thing to note is that enter won't be accepted until that extra character is cleared from the buffer. You can see that demonstrated below

Please let me know if you need more info!

[Kamik423]

Looking through the readchar issues: this might be related to this which references this.

This appears to very much be a readchar issue. Maybe you could post over there and hope they fix it somehow.

I will leave this open for now in case somebody else has this issue (please comment!).

[Cube707]

should be fixed in more recent readchar versions