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

[Khoo Yit Phang <khooyp@cs.umd.edu>]

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