Julian Berman added the comment: Hi, sorry for being terse :).
After checking a bit, man 3 getch says that it returns ERR (-1) in non-blocking mode if no input is available. I think you're right though -- calling ungetch without checking for the error value seems like it should be a bug in the application, and looking at some examples that seems to be correct. The reason this came up though is because the changes to range checking broke bpython, which does something like the code I pasted in the first post. The reason it appears to have worked before is because later on getkey is called, and getkey checks if it got ERR and converts that to an exception, which was being caught and silenced. Now though, the code will fail at the call to ungetch. So, I guess, besides the change in behavior, which I guess is less bug prone before so it's probably desirable, OverflowError sounds scary. Perhaps ungetch should check for -1 and raise a curses.error instead? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16293> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
