Re: Make the "python" command resemble the standard Python interpreter

Doug Evans
2012-01-30T17:19:07Z

On Sun, Jan 29, 2012 at 7:10 PM, Khoo Yit Phang <khooyp@cs.umd.edu> wrote:
> Hi,
>
> On Jan 26, 2012, at 12:43 PM, Doug Evans wrote:
>
>> On Tue, Jan 24, 2012 at 9:30 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>>>> "Doug" == Doug Evans <dje@google.com> writes:
>>>
>>> Doug> I'm not that comfortable with having the python command having such
>>> Doug> varying behaviours (especially based on the value of from_tty).
>>>
>>> What bad effect do you think it will cause?
>>
>> [for example]
>> Suppose I want to cut-n-paste some lines from a script into my session?
>> Maybe as a quick hack or maybe to test something out or whatever.
>>
>> With this change I can't do that for something that contains:
>>
>> python
>> foo
>> end
>
> This scenario works perfectly fine in my current implementation based on from_tty: "python\n" starts the Python REPL, "foo\n" runs in the interpreter, and "end\n" quits the interpreter ("end" by itself in a line is specially recognized as an alternative to Ctrl-D), which has the same outcome as in the script.

Assuming the script didn't intentionally force some keyboard interaction.
[In emacs I sometimes just cut-n-paste a part of a script en masse.]

Plus, with some playing around I found this:

--- foo.gdb - snip ---
python
if 0 == 1:
print "foo"
print "bar"
end
--- snip ---

(gdb) source foo.gdb
bar
(gdb)

But cut-n-paste that script into gdb and I get this:

(gdb) python
if 0 == 1:
print "foo"
print "bar"
end
>>> ... ... File "<stdin>", line 3
print "bar"
^
SyntaxError: invalid syntax
>>>
(gdb)

[For reference sake, here's how I cut-n-pasted it in emacs:
C-x C-f foo.gdb RET C-space C-x ] C-b M-w C-x b RET C-y RET
I hope I transcribed that right.]

Python's repl expects a blank line to end the block.
I don't know if there's a way to work around this. Maybe there is.
So now I'm even less comfortable.