Nadeem Vawda added the comment: > Nadeem: is the failure you show in msg141798 with a version of test_curses that uses pty.openpty?
Yes, I tried the following change:
@@ -328,11 +328,12 @@
- if not sys.__stdout__.isatty():
- raise unittest.SkipTest("sys.__stdout__ is not a tty") # testing setupterm() inside initscr/endwin
# causes terminal breakage
+ import pty
+ _, pty = pty.openpty()
stdscr = curses.initscr()
(I've never used openpty, either in Python or in C, so I can't vouch for
the correctness of this usage.) > If it isn't: I'd expect more test failures on buildbot machines where the buildbot agent is started as a system daemon, in which case the process doesn't have a tty at all. Using pty.openpty it would be possible to ensure that there is a pty that can be used for the test.
Looking at the actual buildbot results, most of the *nix bots I checked
are actually skipping this test; the only one I could find that wasn't is
the "x86 Ubuntu Shared" bot:
So it looks like on most of the bots, buildbot is running without a tty.
Then, test_main() sees that sys.__stdout__ isn't suitable to run the
test, and bails out.
It'd be great if you can come up with a fix that gets the test running
in this environment, but it'll probably be more complicated than just
slotting in a call to openpty().
Python tracker <firstname.lastname@example.org>
Python-bugs-list mailing list