Curses sometimes fails to correctly initialize the terminal. 
Unfortunately I don't know how to reproduce the problem, it was reported
multiple times by ipython users, but I have no idea what causes it.  I
finally found a workaround by making a termios call that at least
restores terminal state (see attachment), but it's just a workaround,
not a real fix.

The issue manifests itself as follows: at some point (I don't know why),
a call to curses.initscr() doesn't actually set the terminal in the
usual mode where input isn't accepted, but instead the terminal
continues accepting normal input, issuing newlines, etc.  The only sign
that curses is active is that in a modern terminal, the scrollbar
changes to fill the screen.  After this, calling curses.endwin(),
instead of restoring terminal state, leaves the terminal in the mode
that typically initscr() would put it in: no input is displayed,
printouts swallow end-of-line characters, etc.

When this happened in ipython sessions, we'd just suggest users call
!reset (the system command), which would restore terminal state.  But
the problem is obviously in curses itself, because once this problem
appeared, running the attached script would always print 'False' for the
state condition checked there.

For now in IPython we have a workaround, but perhaps with this little
description/example, someone who knows the curses code might be able to
actually fix the real problem.  If I find a reliable way to trigger the
bug, I'll add comments here indicating so.

As reported by Ondrej Certik on the IPython mailing list:

Here is how to reliably (100%) reproduce it in ipython 0.8.2 (the bug
indeed goes away in 0.8.4):

http://code.google.com/p/sympy/issues/detail?id=822

together with a screenshot how the terminal looks like (see the
comment #6 for the exact sympy revision to use). Maybe you could use
it to track the bug down in curses, as your patch only seems to be a
workaround (albeit working).

Ondrej

/quote

While unfortunately right now I don't have the time to try and whittle
this down to a smaller, self-contained example, it's great to at least
have a guaranteed reproducible way of triggering the bug.  It requires
installing specific versions of both ipython and sympy, but that's very
straightforward to do, as both are pure-python projects with no
dependencies outside the stdlib.

Is this an issue with 2.7 or 3.1?

That should be, for 2.7 or 3.2, as 3.1 is nearly finished.