Repository maintenance?

[MatteoCampinoti94]

It seems that the automated testings on travis-ci have been given improper instructions, the pull request I sent failed all tests before even reaching the actual code, all because of erroneous instructions given to the test environment. The issue was raised over a year ago but looking at the commits nothing seems to have been done to fix it. Same thing happened to a previous pull request by another user.

Furthermore there have been no answers whatsover by the repository owner.

Is the repository dead or abandoned?

[suresttexas00]

The repo owner is pretty busy, but I don't believe it is abandoned. The tests are also broken for another reason: The test code does not accurately simulate actual user input from the keyboard. It uses a fake buffer that is dependent on certain parts of the code. If you change those parts, the build will not test properly. I don't want to rehash the details again, but I have seen builds from various people (my self included) that worked great in real life, but the test could not detect the keystrokes properly and failed. I gave up on this repo because of the travis test failures.

[suresttexas00]

If interested, you may look at the repo I created to replace this: https://github.com/suresttexas00/readkey

[magmax]

Thank you very much, @suresttexas00 . That is exactly what happens: I'm very busy until June. Anyways, I will try to do my best before the end of Christmas.

Thank you very much for your comments, code and patience.

[MatteoCampinoti94]

Thanks @suresttexas00 and @magmax for the explanation. @magmax @suresttexas00 Built a repo myself too https://github.com/MatteoCampinoti94/python-read Made it modular like yours @magmax while also including my take to reading keys and the getch function to allow for a NONBLOCK flag. Currently trying to test it on windows butfailing to get a correct read with function keys and escape sequences

[suresttexas00]

Mine does work on both windows and *nix machines. I had to be cross platform because the program that uses it is used by windows and linux folks. Windows certainly does things a bit different in their keyboard handling...

[MatteoCampinoti94]

Same here, just finished the windows bit and also added optional manual encoding (found it useful on windows so whatnot, added it to unix to). "A bit" doesn't really describe the unexplainable choices windows people did xp

[MatteoCampinoti94]

@magmax I think I managed to create a semireliable testing script. Simulating keystrokes is nigh-impossible (if at all) to code so instead I tried the next best thing, writing to stdin before calling the read from the module. Used subprocess.Popen and sent the testing characters and escape sequences through in bytes, the module then reads it and returns the what it has read (again in bytes) to test against the sent bytes. It worked flawlessly but had to add an option to disable the raw input for the getch function since termios throws an error when used with the Popen trick. Not a big problem as it could be useful to echo the read and save it to a variable at the same time.

Next step will be to test al chars between 0x00 and 0xff to make sure they all work.

[MatteoCampinoti94]

This is weird, all the tests passed except for 35 '#', 37 '%', 38 '&' (numbers are the decimal ascii values) which work perfectly when tested manually. Number 36 is '$', which I used as a control characters at the end of the key sets to end testing in the subprocess (otherwise a pipe error would have occurred), works perfectly. Tried using manual encoding to utf-8 but that didn't work either. All characters above 127 don't work either during the test though you can use them without problems with the module in normal mode. I think the problems i with how I populate the characters dictionary:

characters = {str(i): chr(i) for i in range(0, 128) if chr(i) != '$'}
characters.update({'ENDTEST': '$'})

Gonna try putting together an hex char using hex

[MatteoCampinoti94]

Nevermind '#' that one fails because I used it as a control character, stillno clue about 37 and 38 though

[mbdevpl]

@MatteoCampinoti94 Some activity by the owner in #27 suggests that repo is not dead :)

And, as @magmax made me a contributor in the repo, I just wanna add that I completely with the notes above -- this package could use better testing. My preliminary runs (in my fork) show that it builds on AppVeyor, but current test coverage is very low (14% now) so it doesn't tell us much.

If you could try to rebase your pull request to the current master, it should pass the tests.