Bouncing Backward Off the Sticky Problem Wall

The riddle goes like this:

How many software engineers does it take to screw in a lightbulb ? 💡

 The Answer:

Zero.
It's a Hardware issue.

Yuk Yuk. But seriously folk. There is this mass hallucination that software lives in a virtual environment of its own, completely isolated from hardware problems.

I just spent hours trying to solve a problem with Python's keyboard.key_read() function.

Theoretically, it should capture a single key press and no more.
So I had made a function called, wait_4c_key with parameters including (...., , allowed = f' "c" or "SPACE"'). The allowed string is inserted into a prompt telling the user to press one of these keys. The function waits for the user to press one of the allowed keys and returns the name of the key once pressed.

So far so good.
I used this wait_4c_key() function to pause my program at the end of each printout of a series lesson statements. Never mind what that content was. The pause worked fine for a first couple of screen-fills. But then, ... it would fail to pause and just skip past a screen-full of stuff as if I had pressed the key when in fact I hadn't.

Lot's of time was spent looking for why this could happen. Some sites mentioned the possibility of a key-press "echo". Various solutions were proposed.

None of the online proposals worked on my computer.

I don't know how the hardware on my computer actually works. Maybe there is some buffer that gets loaded with the last key press and then doesn't get cleared? I don't know. But what if I did a double key board read in quick succession like this:

It worked !! Don't know exactly why.

(Left click one below image to see it bigger, clearer)

More to Explore 

(1) How to detect keypress in python
(2) Keyboard automation using python
(3) How to Detect Key Presses with Python (by the Russian?)
(4) The Millan S Academy (the Russian?) Playlists
(5)