From: Tom Tromey <tromey@redhat.com>
To: Khoo Yit Phang <khooyp@cs.umd.edu>
Cc: gdb-patches@sourceware.org
Subject: Re: Make the "python" command resemble the standard Python interpreter
Date: Wed, 11 Jan 2012 20:56:00 -0000 [thread overview]
Message-ID: <m3d3aq55ew.fsf@fleche.redhat.com> (raw)
In-Reply-To: <A6FE1BE9-CD08-41A2-A1E8-F659140DA689@cs.umd.edu> (Khoo Yit Phang's message of "Tue, 10 Jan 2012 19:18:37 -0500")
>>>>> "Yit" == Khoo Yit Phang <khooyp@cs.umd.edu> writes:
Yit> I'd like to contribute a patch to improve the "python" command by
Yit> making it resemble the standard Python interpreter in behavior.
Thanks.
Do you have a copyright assignment in place?
If not, contact me off-list and I will get you started.
We need this before we can incorporate this patch.
Yit> For "python" with arguments, this prints the results of expressions,
Yit> e.g., "python 1 + 2" will print "3" (previously, it will not print
Yit> anything).
Did you run the test suite? I'm curious if this caused any failures.
On balance, I'm ok with this idea, since I don't think we make many
promises about CLI output remaining the same across versions.
Yit> For "python" without arguments, this uses Python's built-in
Yit> interactive loop (PyRun_InteractiveLoop) so that individual
Yit> statements/expressions are immediately evaluated and results of
Yit> expressions are printed.
Sounds nice.
This also seems like it could cause some (spurious) test failures.
Yit> It also hooks GDB's readline wrappers
Yit> (command_line_input) to Python so that line editing and history
Yit> editing works. Additionally, Python's standard readline module is
Yit> stubbed out because it conflicts with GDB's use of readline.
Can you expand more on how it conflicts?
I think it would be better to make it not conflict somehow.
Yit> + TRY_CATCH (except, RETURN_MASK_ALL)
Yit> + {
Yit> + struct cleanup *cleanup = gdbpy_suspend_sigint_handler ();
Yit> + p = command_line_input (prompt, 0, "python");
Yit> + do_cleanups (cleanup);
Yit> + }
Yit> +
Yit> + /* Detect Ctrl-C and treat as KeyboardInterrupt. */
Yit> + if (except.reason == RETURN_QUIT)
Yit> + return NULL;
Does this case need the Python exception to be set? If not, I think it
would be good to expand this comment to explain the situation.
Yit> + m = PyImport_AddModule ("__main__");
Yit> + if (m == NULL)
Yit> + error (_("Error while executing Python code."));
You have to do something with the Python exception here.
Usually we use gdbpy_print_stack, but sometimes other things are
appropriate.
Yit> + d = PyModule_GetDict (m);
Do we need error checking?
I didn't look at the API docs.
Yit> + v = PyRun_StringFlags (command,
Yit> + from_tty ? Py_single_input : Py_file_input,
Yit> + d, d, NULL);
Yit> + if (v == NULL)
Yit> + {
Yit> + int interrupt = PyErr_ExceptionMatches (PyExc_KeyboardInterrupt);
Yit> + PyErr_Print ();
gdbpy_print_stack.
Yit> + if (! interrupt)
Yit> + error (_("Error while executing Python code."));
Why the special case for interrupts here?
Tom
next prev parent reply other threads:[~2012-01-11 20:51 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-11 0:31 Khoo Yit Phang
2012-01-11 4:06 ` Joel Brobecker
2012-01-11 10:43 ` Kevin Pouget
2012-01-11 10:59 ` Joel Brobecker
2012-01-11 16:04 ` Khoo Yit Phang
2012-01-11 17:48 ` Khoo Yit Phang
2012-01-11 18:48 ` Kevin Pouget
2012-01-11 19:04 ` Khoo Yit Phang
2012-01-11 19:11 ` Kevin Pouget
2012-01-11 21:06 ` Khoo Yit Phang
2012-01-11 21:33 ` Tom Tromey
2012-01-11 22:22 ` Khoo Yit Phang
2012-01-20 21:25 ` Tom Tromey
2012-01-20 21:31 ` Tom Tromey
2012-01-22 16:42 ` Khoo Yit Phang
2012-01-11 20:56 ` Tom Tromey [this message]
2012-01-11 21:30 ` Khoo Yit Phang
2012-01-11 21:41 ` Tom Tromey
2012-01-12 3:07 ` Khoo Yit Phang
2012-01-13 14:09 ` Phil Muldoon
2012-01-13 21:39 ` Khoo Yit Phang
2012-01-12 16:48 ` Doug Evans
2012-01-12 16:52 ` Khoo Yit Phang
2012-01-12 16:55 ` Paul_Koning
2012-01-12 17:24 ` Joel Brobecker
2012-01-12 17:30 ` Doug Evans
2012-01-12 17:38 ` Paul_Koning
2012-01-12 17:46 ` Doug Evans
2012-01-12 17:48 ` Doug Evans
2012-01-12 17:51 ` Paul_Koning
2012-01-12 18:06 ` Doug Evans
[not found] ` <CADPb22T1ZmfiGeF9g-QZN6pCTBHwT5ByD9ddX_Dhxe4URvTAhw@mail.gmail.com>
2012-01-12 18:21 ` Khoo Yit Phang
2012-01-12 18:36 ` Doug Evans
2012-01-12 18:48 ` Khoo Yit Phang
2012-01-12 21:22 ` Doug Evans
2012-01-12 18:30 ` Doug Evans
2012-01-21 1:56 ` Tom Tromey
2012-01-22 16:57 ` Khoo Yit Phang
2012-01-23 22:17 ` Doug Evans
2012-01-24 17:36 ` Tom Tromey
2012-01-26 18:28 ` Doug Evans
2012-01-30 6:50 ` Khoo Yit Phang
2012-01-30 17:25 ` Doug Evans
2012-01-30 19:57 ` Doug Evans
2012-02-06 20:08 ` Doug Evans
2012-02-06 20:13 ` Paul_Koning
2012-02-06 20:30 ` Khoo Yit Phang
2012-02-06 20:34 ` Doug Evans
2012-02-06 20:59 ` Paul_Koning
2012-02-06 21:54 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3d3aq55ew.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=khooyp@cs.umd.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox