Using python 2.3.3 on gentoo I have the following problem:

When calling stdscr.getkey() in raw mode, the program
crashes on a terminal resize event. In cooked and
cbreak modes, the proper string is returned -
"KEY_RESIZE". This problem appeared after upgrading
from python 2.3.2, I believe. Below is a quick program
that exhibits this behavior on my machine.

#######################################################
#!/usr/bin/env python

import curses;

stdscr = curses.initscr();
curses.raw();
curses.noecho();
stdscr.keypad(1);

while(1):
  stdscr.clear();
  stdscr.addstr("Enter key: ");
  c = stdscr.getkey();
  if(c == 'q'):
    break;
  stdscr.clear();
  stdscr.addstr('"' + c + '"\n\n');
  stdscr.addstr("Press any key...");
  stdscr.getkey();

curses.noraw();
curses.endwin();
#######################################################

A couple of other notes: 
1) No exception is thrown (a try block doesn't catch it).
2) The behavior is the same using the interactive
interpreter.
3) The traceback is: File "./keyname", line 19, in ?
stdscr.getkey(); _curses.error: no input

Logged In: YES 
user_id=11375

1) and 3) are contradictory; 3 is certainly an exception
traceback.
When I try the test program on a Debian system, I get the
same error,
but a try:except: around the getkey() on line 19 lets the
program continue running.

Nothing in the Python curses module changed between 2.3.3
and 2.3.2.  Did gentoo switch to a new revision of the
ncurses library, perhaps?

Logged In: YES 
user_id=971407

That Gentoo updated the ncurses library is quite possible.
Though the behavior is still incorrect as the documentation
says that getkey will return "KEY_RESIZE" on a terminal
resize event, and in fact it does in cooked and cbreak
modes, but throws an exception when in raw mode (though a
terminal resize isn't an exceptional circumstance).  Also, a
program can't assume that an exception on getkey() is a
resize event because an actual exception might occur and
need to be dealt with. 

For the present, though, the workaround is acceptable
because a real exception on getkey is very unlikely, as far
as I can see.

Logged In: YES 
user_id=11375

After experimenting a bit with the attached test program, it
doesn't seem as if this is actually a bug in
the module; the ncurses docs themselves are vague on the
interaction between signals and a KEY_RESIZE.  So I'll close
this bug, because it doesn't look like there's anything in
Python to fix.

Logged In: YES 
user_id=11375

Forgot to attach the script I was using.