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

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

Hi,

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

> On Thu, Jan 12, 2012 at 10:19 AM, Khoo Yit Phang <khooyp@cs.umd.edu> wrote:
>> 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.
> 
> Heh.  / is for display options (e.g. x/i $pc), - is for other kinds of
> options (e.g. symbol-file -readnow foo).
> But yeah, that's another alternative.  [It feels more problematic,
> e.g. the caveat you mention.]

For reference, the caveat I mentioned was in an email rejected by the mailing list server: that was for "python -i" which would disallow the python script "-i".

"python /i" would not have this caveat, since "/i" isn't a valid Python expression.

Yit
January 12, 2012