homepage

The following code now raises an OverflowError on 3.3:
import curses
def test_screen(screen):
 screen.nodelay(True)
 key = screen.getch()
 screen.nodelay(False)
 curses.ungetch(key)
curses.wrapper(test_screen)
or equivalently just
def test_screen(screen):
 curses.ungetch(-1)

Do you consider this behaviour as a bug? What is the behaviour in C?
Le 21 oct. 2012 03:25, "Julian Berman" <report@bugs.python.org> a écrit :
>
> New submission from Julian Berman:
>
> The following code now raises an OverflowError on 3.3:
>
> import curses
>
> def test_screen(screen):
> screen.nodelay(True)
> key = screen.getch()
> screen.nodelay(False)
> curses.ungetch(key)
>
> curses.wrapper(test_screen)
>
> or equivalently just
>
> def test_screen(screen):
> curses.ungetch(-1)
>
> ----------
> components: Library (Lib)
> messages: 173425
> nosy: Julian, haypo
> priority: normal
> severity: normal
> status: open
> title: curses.ungetch raises OverflowError when given -1
> versions: Python 3.3, Python 3.4, Python 3.5
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue16293>
> _______________________________________
>

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?

The following example returns immediatly, whereas I expected it to block. So I consider that ungetch(-1) should fail, but I may be wrong.
---
import curses
def test_screen(screen):
 screen.nodelay(True)
 key = screen.getch()
 screen.nodelay(False)
 curses.ungetch(key)
 screen.getch()
curses.wrapper(test_screen)
---
key is -1, I don't get an OverflowError. The Python implementation of ungetch() casts the Python int to a C "chtype" type, and check for underflow or overflow. On my Fedora 18, chtype is defined in ncurses.h as "unsigned long". My code checking for overflow doesn't detect the overflow for this specific case.
What is your platform (name and version)?
We should always have the same behaviour on any platform (always fail with an error, or always accept -1), so anyway there is a bug.

This looks like a bug in ncurses 5.7 and a duplicate of issue 15037.