On Fri, 25 Feb 2011 11:50:35 -0500, Andrew wrote: > I find that calling getpass produces a warning noting that it can't > suppress output, if I'm using idle, wingide, or a few others. If I'm > running from the console it works fine, but then I can't make use of > ide-integrated debugging. > > I know I could just set up a test account for development purposes if > I'm concerned about shoulder surfers, and that's probably a good idea > anyway. But I'm curious what's different about IDE environments that > makes it impossible to suppress output on them, and if there's anything > that might be done about this.
This suggests that the Python interpreter isn't getting a controlling terminal when spawned from the IDE. If I run IDLE from a shell, IDLE inherits the shell's controlling terminal, which the interpreter inherits from IDLE. So getpass() works correctly, but it uses the original terminal not the IDLE window. If IDLE is spawned from a desktop environment, there probably won't be any controlling terminal. The odd thing is that the Python interpreter spawned from IDLE inherits its (real) std{in,out,err} from IDLE. If IDLE was started from a terminal, the interpreter will have that its standard descriptors associated with the terminal. But the Python sys.std{in,out,err} objects are of type idlelib.rpc.RPCProxy. This means that anything written via e.g. "print" or "sys.stdout.write()" will be sent to IDLE, while e.g. os.write() or child process will use the inherited descriptors. This behaviour isn't inevitable; it's just the way IDLE works. If an IDE allocates a pty for the interpreter, and the IDE doesn't already have a controlling terminal, the pty will become the controlling terminal unless it explicitly prevents this (by openeing it with the O_NOCTTY flag). -- http://mail.python.org/mailman/listinfo/python-list