Here is the output from test_pty.py:

capulet:dist/src > ./python Lib/test/test_pty.py
Calling master_open()
Got master_fd '3', slave_name '/dev/pts/0'
Calling slave_open('/dev/pts/0')
Got slave_fd '4'
Traceback (most recent call last):
  File "Lib/test/test_pty.py", line 58, in ?
    test_basic_pty()
  File "Lib/test/test_pty.py", line 29, in 
test_basic_pty
    if not os.isatty(slave_fd):
  File "Lib/test/test_pty.py", line 50, in handle_sig
    raise TestFailed, "isatty hung"
test.test_support.TestFailed: isatty hung


This was running Python 2.3a2 (downloaded from 
CVS on Sunday 30th March) built on HP-UX11i.

Logged In: YES 
user_id=6656

Neal?  I thought you thought this was fixed?

Logged In: YES 
user_id=33168

I fixed the test hanging, but not the actual bug.  The bug
appears when running test_pty after test_openpty.  There's
some interaction, but I don't know what it is.  The problem
happens on AIX also.  I searched through some man pages, but
nothing leapt out at me.  I think I tried googling for the
answer to no avail. Any insight or ideas would be helpful. 
This may have started when adding /dev/ptmx (ptc for AIX)
support.

Logged In: YES 
user_id=33168

Actually, there is a 'fix' which is really a work-around the
problem.  You can disable os.openpty() in pty.master_open. 
I added a raise OSError at line 50 (before os.openpty()). 
This allows the test to pass.  I think Martin and I agreed
that globally disabling wasn't the best solution.  That
would probably be in some patch.

Also, just in case it isn't clear--if you run test_pty
BEFORE test_openpty, both tests pass.

Logged In: YES 
user_id=994239

I'm running into this problem under both AIX 4.3.3 and 5.1.
 Is this going to cause a problem if I put python into
produciton, or is it "safe" to ignore it?

Logged In: YES 
user_id=200117

This still happens with Python-2.4.0a1 on HP-UX11i

Logged In: YES 
user_id=987664

This happens with Python 2.4 on Tru64Unix V5.1 when
compiling using gcc-3.4.3, but not if you use the vendor cc.

Logged In: YES 
user_id=33168

Can you test with the patch in bug report: 
https://sourceforge.net/tracker/index.php?func=detail&aid=1433877&group_id=5470&atid=105470
?  I wonder if that fixes the problem.  Though I'm not sure
the same code is executed or not.

Logged In: YES 
user_id=1469902

I have the same problem with Python 2.4.2 running on AIX 5.2.

The test test_pty hangs for 10 seconds after which it is
aborted by a time-out condition. I have traced the system
calls and it turns out that the following scenario occurs:

1) os.write(slave_fd, TEST_STRING_2[:5])
2) os.write(slave_fd, TEST_STRING_2[5:])
3) s2 = os.read(master_fd, 1024)
[...]
4) os.close(slave_fd)

At 3) we only read the first part of the string written in
1) and not the complete string written in both 1) and 2).
The close() call then hangs in 4) (as it is waiting for
slave_fd to be flushed?).

The solution is to continue reading until a newline
character is read ie. readling a complete line. The patch is
shown below.

*** Lib/test/test_pty.py.orig   2004-02-12 7:35:11.000000000
+0000
--- Lib/test/test_pty.py        2006-03-07 2:05:39.000000000
+0000
***************
*** 40,47 ****
      debug("Writing chunked output")
      os.write(slave_fd, TEST_STRING_2[:5])
      os.write(slave_fd, TEST_STRING_2[5:])
!     s2 = os.read(master_fd, 1024)
!     sys.stdout.write(s2.replace("\r\n", "\n"))
  
      os.close(slave_fd)
      os.close(master_fd)
--- 40,49 ----
      debug("Writing chunked output")
      os.write(slave_fd, TEST_STRING_2[:5])
      os.write(slave_fd, TEST_STRING_2[5:])
!     s2 = "";
!     while not s2 or s2[-1] != "\n":
!         s2 = s2 + os.read(master_fd, 1024)
!     sys.stdout.write(s2.replace("\r\n", "\n"));
  
      os.close(slave_fd)
      os.close(master_fd)

Unless this still is a confirmed problem in supported platforms, closing
suggested.

Closed as suggested in msg81496.