This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Make the "python" command resemble the standard Python interpreter
- From: Khoo Yit Phang <khooyp at cs dot umd dot edu>
- To: <Paul_Koning at Dell dot com>
- Cc: Khoo Yit Phang <khooyp at cs dot umd dot edu>, <dje at google dot com>, <tromey at redhat dot com>, <gdb-patches at sourceware dot org>
- Date: Mon, 6 Feb 2012 15:30:03 -0500
- Subject: Re: Make the "python" command resemble the standard Python interpreter
- References: <A6FE1BE9-CD08-41A2-A1E8-F659140DA689@cs.umd.edu> <CADPb22SxGFEsAEQ3AvNnbcjWR8QPWDWC-LYq_bnpMQ1awZ_j3A@mail.gmail.com> <09787EF419216C41A903FD14EE5506DD030F1EB39B@AUSX7MCPC103.AMER.DELL.COM> <CADPb22QfoNKJr=c897GFO-RD69Lrd0HuEV2jBjanV8ZB1mb-DQ@mail.gmail.com> <09787EF419216C41A903FD14EE5506DD030F1EB45D@AUSX7MCPC103.AMER.DELL.COM> <CADPb22SV+8UW2pAO-7zdWxzOyQt2oL+aTRV8ik7AtHQ5Z3wWhQ@mail.gmail.com> <m3y5t2t6g9.fsf@fleche.redhat.com> <D8EAF73C-5BD3-4E6D-8F33-2C5BA229923C@cs.umd.edu> <CADPb22QMDkH+1veSGaKCd6FQHqqGSgovDbG8NxROsHc4PLPa5w@mail.gmail.com> <m3d3a9c8jd.fsf@fleche.redhat.com> <CADPb22R81ctfSXvU1rodeyqxwfPhVihU4m+pOC2FhXARYwrZHw@mail.gmail.com> <E4F090B1-72AE-4891-BF56-56C46028422F@cs.umd.edu> <CADPb22RzB765fDbNLeJ392eVSfnbgS4eSw1uP3q54q4yv+kkRQ@mail.gmail.com> <CADPb22SDZypdCyLq5NncG7A-c0OsuxuzQsofYOEnAak-jGsfJQ@mail.gmail.com> <CADPb22Sz+=7qvVW_COy_tqKxaBd5CHjeuARwwHAi1-c5Ksb_QA@mail.gmail.com> <09787EF419216C41A903FD14EE5506DD0310E29D2F@AUSX7MCPC103.AMER. DELL.COM>
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