This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Julian
Recipients Julian, vstinner
Date 2012-10-21.13:53:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1350827583.36.0.0336314357307.issue16293@psf.upfronthosting.co.za>
In-reply-to
Content
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?
History
Date User Action Args
2012-10-21 13:53:03Juliansetrecipients: + Julian, vstinner
2012-10-21 13:53:03Juliansetmessageid: <1350827583.36.0.0336314357307.issue16293@psf.upfronthosting.co.za>
2012-10-21 13:53:03Julianlinkissue16293 messages
2012-10-21 13:53:03Juliancreate