This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Hi,

On Jan 12, 2012, at 1:13 PM, Doug Evans wrote:

> On Jan 12, 2012 9:51 AM, "Doug Evans" <dje@google.com> wrote:
> >
> > On Thu, Jan 12, 2012 at 9:47 AM,  <Paul_Koning@dell.com> wrote:
> > >>...
> > >>> - I may want a script that invokes python interactively.
> > >>> - How do I write a gdb macro that invokes the python repl?
> > >>>
> > >>> Solve those problems, and provide a migration path away from the old
> > >>> behaviour, and then you've got something.
> > >>
> > >>As a strawman, a new command, python-foo, could be provided [python-code?  python-script?] that had the "old" behaviour.
> > >
> > > Nice solution.
> >
> > btw, would we ever want to pass options to the python repl?
> > If that might ever occur, then we don't want python with arguments to
> > be the old behaviour.
> 
> Or preferably have a new command should the need arise (I like python-repl, but I realize repl may be too obscure :-) ).
> OK, I think I'm OK with where this is going.

Instead of making a new command, we can add an option to, say "python /i", that forces the interpreter to start, so that you can define a GDB macro that starts a Python interpreter (when from_tty is false). That would retain compatibility with the current behavior.

Yit
January 12, 2012


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]