467,074 Members | 914 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,074 developers. It's quick & easy.

Running an interactive interpreter inside a python

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.

Jun 27 '08 #1
  • viewed: 1625
Share:
3 Replies
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

On May 15, 11:31 am, ro...@panix.com (R. Bernstein) wrote:
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.
Jun 27 '08 #2
"Alan J. Salmoni" <sa*****@gmail.comwrites:
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.

>
On May 15, 11:31 am, ro...@panix.com (R. Bernstein) wrote:
>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.
Jun 27 '08 #3
On May 15, 6:26*am, ro...@panix.com (R. Bernstein) wrote:
"Alan J. Salmoni" <salm...@gmail.comwrites:
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.


On May 15, 11:31 am, ro...@panix.com (R. Bernstein) wrote:
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.- Hide quoted text -

- Show quoted text -
One threat is malicious code; sorry for this.
Jun 27 '08 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

147 posts views Thread by Sateesh | last post: by
6 posts views Thread by Avi Berkovich | last post: by
8 posts views Thread by Paul Cochrane | last post: by
5 posts views Thread by linuxnow@gmail.com | last post: by
10 posts views Thread by notejam | last post: by
reply views Thread by Simon Eves | last post: by
4 posts views Thread by yan.python@gmail.com | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.