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

Khoo Yit Phang
2012-02-06T20:30:20Z

Hi,

Doug is right: Python's standard REPL (read-eval-print-loop), i.e., what you get when you run "python" from the shell or call the PyRun_InteractiveLoop function, has a slightly different behavior when defining the outermost block. (See some example transcripts at the end.)

So, copying and pasting in (non-GDB) Python has the hazards Doug is worried about. I suppose it's preferable to avoid this hazard in GDB's Python, probably by introducing another command such as "python-block".

Alternatively, I suppose it's possible to work around PyRun_InteractiveLoop by detecting a newline without indent, if we're willing to diverge from standard Python.

Yit
February 6, 2012

bash> python
Python 2.7.2 (default, Nov 21 2011, 15:04:09)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> if 1 == 1:
... print 1
... if 2 == 2:
File "<stdin>", line 3
if 2 == 2:
^
SyntaxError: invalid syntax
>>> if 1 == 1:
... print 1
...
1
>>> def foo():
... return 1
... def bar():
File "<stdin>", line 3
def bar():
^
SyntaxError: invalid syntax
>>> def foo():
... return 1
...

On Feb 6, 2012, at 3:13 PM, <Paul_Koning@Dell.com> wrote:

> I'm confused. "Python's repl expects a blank line to end a block"? I'm not sure what a repl is, but Python doesn't require blank lines for anything. End of block is defined by smaller indent.
>
> I don't understand that error message at all.
>
> paul
>
> -----Original Message-----
> From: Doug Evans [mailto:dje@google.com]
> Sent: Monday, February 06, 2012 3:09 PM
> To: Khoo Yit Phang
> Cc: Tom Tromey; Koning, Paul; gdb-patches@sourceware.org
> Subject: Re: Make the "python" command resemble the standard Python interpreter
>
> On Mon, Jan 30, 2012 at 9:25 AM, Doug Evans <dje@google.com> wrote:
>> On Mon, Jan 30, 2012 at 9:18 AM, Doug Evans <dje@google.com> wrote:
>>> 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.
>>
>> btw, that's with the latest python-interactive script (that I could
>> find) applied (+ the sigint patch too).
>>
>> For grin's sake, there's another example:
>>
>> --- snip ---
>> python
>> if 0 == 1:
>> print "foo"
>> end
>> ---
>>
>> If I cut-n-paste that into gdb the "end" terminates the "if" block
>> (heh, didn't expect that :-)), and afterwards I'm still in python.
>> Maybe this can be fixed too.
>
> btw, in an effort to keep things moving along, to repeat something I mentioned earlier, If you, for example, add a new command, say, "python-block" ('tis the best I could come up with :-() that always behaved like python...end in scripts, then I think that would be ok: Users that want the existing script-like behaviour can switch to and use it instead of "python". IOW, "python-block" always behaves like the existing "python" command without arguments.
>
> E.g.,
>
> python-block
> if 0 == 1:
> print "foo"
> end