Make the "python" command resemble the standard Python interpreter

[Khoo Yit Phang]

Hi,

On Jan 11, 2012, at 4:30 PM, Tom Tromey wrote:

>>>>>> "Yit" == Khoo Yit Phang <khooyp@cs.umd.edu> writes:
> 
> Yit> Attached is a new patch that uses another way to disable the readline
> Yit> module, which works with pdb.set_trace(). However, readline support
> Yit> still doesn't work with pdb. The reason is because pdb uses raw_input,
> Yit> which in turn uses sys.stdin/sys.stdout to determine whether to use
> Yit> readline, but GDB replaces sys.stdin/sys.stdout with it's own
> Yit> file-like objects that isn't recognized as a tty by Python.
> 
> This sounds like http://sourceware.org/bugzilla/show_bug.cgi?id=12150
> Maybe we should try to fix that instead?

Yes, it's related, if I understand correctly, sys.stdout/sys.stderr are overridden the way they are so that GDB can capture/filter the output. Another solution, besides overriding raw_input/input, would be to point sys.stdout/sys.stderr to a PTY, though I'm not sure what the trade-offs are.

> Yit> Making Python's readline module work under GDB is not possible, since
> Yit> it re-initializes libreadline and generally assumes that libreadline
> Yit> is completely under Python's control (and libreadline itself has no
> Yit> support for nesting/reentrancy).
> 
> The initialization shouldn't be a problem.
> 
> Calling rl_initialize multiple times is ok -- readline() itself calls
> it.

However, other configuration cannot be set repeatedly, e.g., rl_readline_name, rl_completion_*, various rl_*_hook, keybindings, and so on.

> I don't know about the reentrancy though.  Also, IIRC, gdb uses the
> unusual async interface.  Maybe that raises some issues.

That may explain another issue I've seen where inputs are delayed by one keystroke.

Yit
January 11, 2011