Running an interactive interpreter inside a python

[R. Bernstein]

The next release of pydb will have the ability to go into ipython from
inside the debugger. Sort of like how in ruby-debug you can go into
irb

For ipython, this can be done pretty simply; there is an IPShellEmbed
method which returns something you can call. But how could one do the
same for the stock python interactive shell?

To take this out of the realm of debugging. What you want to do is to
write a python program that goes into the python interactive shell -
without having to write your own a read/eval loop and deal with
readline, continuation lines, etc.

The solution should also allow
- variables/methods in the calling PYthon program to be visible
in the shell
- variables set in the interactive (sub) shell should persist after the shell
terminates, although this is a weaker requirement. POSIX subshells
for example *don't* work this way.

There has been much written about how to embed Python from C, so I
suppose this may offer one way. And at worst, I could write
a C extension which follows how C Python does this for itself.

But is there a simpler way?

Thanks.

 

[Alan J. Salmoni]

I'm not sure if this is exactly what you're after, but try looking
into the 'code' module.

It's fairly easy to make an interactive interpreter that runs within
your program. If you import your programs variables into
__main__.__dict__, you can have access to them which can be funky. You
can even override the showtraceback method to catch various exceptions
and do daft things like adding new methods to strings. I guess it
would even be possible to have the commands compared to a list of
commands and keywords to build a restricted interpreter, though how
secure this would be against a determined attack is another matter.

Alan

 

[R. Bernstein]

I'm not sure if this is exactly what you're after, but try looking
into the 'code' module.

It's fairly easy to make an interactive interpreter that runs within
your program. If you import your programs variables into
__main__.__dict__, you can have access to them which can be funky. You
can even override the showtraceback method to catch various exceptions
and do daft things like adding new methods to strings. I guess it
would even be possible to have the commands compared to a list of
commands and keywords to build a restricted interpreter, though how
secure this would be against a determined attack is another matter.

Alan

I think this (largely) does the trick. Thanks!

I'm not sure about how to deal with globals yet which should come from
a stackframe f_globals. It might be possible to save and restore
__main__.__dict__ before and after the call to interact(). Probably
would have been cooler to design interact() to take a globals
parameter, same as eval does.

 

[castironpi]

I think this (largely) does the trick. Thanks!

I'm not sure about how to deal with globals yet which should come from
a stackframe f_globals. It might be possible to save and restore
__main__.__dict__ before and after the call to interact(). Probably
would have been cooler to design interact() to take a globals
parameter, same as eval does.






- Show quoted text -

One threat is malicious code; sorry for this.

 

[R. Bernstein]

One threat is malicious code; sorry for this.

This is a little too cryptic for me. But then if we're talking
security, maybe obfuscation is in order.

If this was meant as an explanation for why interact() only takes a
local parameter and none for global, security concerns are in fact why
you'd want to *add* that parameter: so that the caller could more easily
decide what interact sees as global. I haven't tried implementing a
__main__.__dict__ save, modify and restore around the interact(), but
I'll assume that this could be made to work.

If instead this was about the evils of writing a program that uses
code and calls interact, in general, debuggers and security are at
odds. In a highly secure environment, you probably want to disallow
any trace hook. I think Ruby uses the global variable $SAFE with a
particular level setting for this purpose.