From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14133 invoked by alias); 6 Feb 2012 20:30:20 -0000 Received: (qmail 14123 invoked by uid 22791); 6 Feb 2012 20:30:19 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from router-304.cs.umd.edu (HELO bacon.cs.umd.edu) (128.8.127.145) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 06 Feb 2012 20:30:06 +0000 Received: from wireless-206-196-165-237.umd.edu (wireless-206-196-165-237.umd.edu [206.196.165.237]) (Authenticated sender: khooyp) by bacon.cs.umd.edu (Postfix) with ESMTPSA id C51FCB402FB; Mon, 6 Feb 2012 15:30:03 -0500 (EST) Subject: Re: Make the "python" command resemble the standard Python interpreter Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Khoo Yit Phang In-Reply-To: <09787EF419216C41A903FD14EE5506DD0310E29D2F@AUSX7MCPC103.AMER.DELL.COM> Date: Mon, 06 Feb 2012 20:30:00 -0000 Cc: Khoo Yit Phang , , , Content-Transfer-Encoding: quoted-printable Message-Id: References: <09787EF419216C41A903FD14EE5506DD030F1EB39B@AUSX7MCPC103.AMER.DELL.COM> <09787EF419216C41A903FD14EE5506DD030F1EB45D@AUSX7MCPC103.AMER.DELL.COM> <09787EF419216C41A903FD14EE5506DD0310E29D2F@AUSX7MCPC103.AMER. DELL.COM> To: X-CSD-MailScanner-ID: C51FCB402FB.AB675 X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-50, required 5, autolearn=not spam, ALL_TRUSTED -50.00) X-CSD-MailScanner-From: khooyp@cs.umd.edu X-CSD-MailScanner-Watermark: 1329165003.9541@TY1pxc5GXbJyRXORwsICCw Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-02/txt/msg00067.txt.bz2 Hi, Doug is right: Python's standard REPL (read-eval-print-loop), i.e., what yo= u get when you run "python" from the shell or call the PyRun_InteractiveLoo= p function, has a slightly different behavior when defining the outermost b= lock. (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, pro= bably 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 st= andard Python.=20 Yit February 6, 2012 bash> python Python 2.7.2 (default, Nov 21 2011, 15:04:09)=20 [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> if 1 =3D=3D 1: ... print 1 ... if 2 =3D=3D 2: File "", line 3 if 2 =3D=3D 2: ^ SyntaxError: invalid syntax >>> if 1 =3D=3D 1: ... print 1 ...=20 1 >>> def foo(): ... return 1 ... def bar(): File "", line 3 def bar(): ^ SyntaxError: invalid syntax >>> def foo(): ... return 1 ...=20 On Feb 6, 2012, at 3:13 PM, 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 anythin= g. End of block is defined by smaller indent. >=20 > I don't understand that error message at all. >=20 > paul >=20 > -----Original Message----- > From: Doug Evans [mailto:dje@google.com]=20 > 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 inter= preter >=20 > On Mon, Jan 30, 2012 at 9:25 AM, Doug Evans wrote: >> On Mon, Jan 30, 2012 at 9:18 AM, Doug Evans wrote: >>> Plus, with some playing around I found this: >>>=20 >>> --- foo.gdb - snip --- >>> python >>> if 0 =3D=3D 1: >>> print "foo" >>> print "bar" >>> end >>> --- snip --- >>>=20 >>> (gdb) source foo.gdb >>> bar >>> (gdb) >>>=20 >>> But cut-n-paste that script into gdb and I get this: >>>=20 >>> (gdb) python >>> if 0 =3D=3D 1: >>> print "foo" >>> print "bar" >>> end >>>>>> ... ... File "", line 3 >>> print "bar" >>> ^ >>> SyntaxError: invalid syntax >>>>>>=20 >>> (gdb) >>>=20 >>> [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=20 >>> transcribed that right.] >>>=20 >>> 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. >>=20 >> btw, that's with the latest python-interactive script (that I could >> find) applied (+ the sigint patch too). >>=20 >> For grin's sake, there's another example: >>=20 >> --- snip --- >> python >> if 0 =3D=3D 1: >> print "foo" >> end >> --- >>=20 >> If I cut-n-paste that into gdb the "end" terminates the "if" block=20 >> (heh, didn't expect that :-)), and afterwards I'm still in python. >> Maybe this can be fixed too. >=20 > btw, in an effort to keep things moving along, to repeat something I ment= ioned 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 arg= uments. >=20 > E.g., >=20 > python-block > if 0 =3D=3D 1: > print "foo" > end