[IPython-user] help with embedding
Fri Jul 11 06:01:28 CDT 2008
thanks for these detailed comments. I'll do my best to help a bit...
On Tue, Jul 8, 2008 at 8:31 AM, David M. Kaplan <firstname.lastname@example.org> wrote:
> 1) Calling keyboard() from ipython itself seems to drop me into a new
> namespace that doesn't know anything about the variables in the original
> ipython namespace. I can fix this by setting the local or global
> namespace to _ip.user_ns. Can someone explain why this is necessary?
> Naively, I would expect to end up in the ipython namespace just as
> calling keyboard() from a script does.
The embedded shells are intended to study the *local* namespace of
where they are called, not to manipulate the enclosing ipython
namespace. I should note that you can pass the namespace that you
want to hold in the locals/globals when you construct the instance,
but that may be already what you are doing (I wasn't sure if you were
doing it at construction time or manually later).
But more importantly: you are nesting embedded shells inside a running
ipython. Unfortunately there's enough global state in ipython and
readline that having embedded instances without any funny business is
a bit tricky. Some of it can be cleaned up via more careful handling
of the readline state when going in/out of the embedded shell, other
parts would require a bit more work on the assumptions ipython makes
about global state. It's all fixable, but there could be some
relatively serious surgery required.
> 2) The restriction to not being able to modify variables is a bit of a
> pain. In matlab, I often use keyboard to give information to my
> scripts. Is there a way around this? Or is there another approach I
> should be using?
There's no way around it, it's a limitation imposed by python itself:
the locals dict obtained from the stack is read-only.
> 3) When I create the shell instance, it spits out information about the
> logging state, as if I had just started ipython. This makes some sense
> as it is like starting a new ipython, but this has a strange interaction
> with the ipython history. All the commands I enter end up in
> ipython_log.py, but when I create the instance from inside ipython
> itself, it has the effect of making ipython "forget" about previous
> commands. If I use the up arrow key to flip through previous commands,
> all commands from the current session are absent, including the command
> I used to create the embedded ipython instance. Is this normal?
> 3) Once I finish in the embedded shell, I enter %quit and leave it.
> After this, attempting to reuse the keyboard() immediately exits the
> shell. Presumably it is dead. Is there a way to make an embedded shell
> that stays alive or to bring back to life a dead shell? Or do I need to
> create a new instance each time?
> 4) If I create, use and exit an embedded shell, either from ipython
> itself or in a script I execute with %run (and possibly other ways), and
> then I try to use the %quit magic command to exit ipython, it does
> nothing. It asks if I want to leave, I enter y, hit enter and then it
> just puts me right back in ipython. The only way I have found to exit
> is with ctrl-d. This seems like a bug to me. Am I correct?
All of these are really problems with nesting ipython with embedded
instances. In the long term these should be fixed, so I'd enocourage
you to file them as bug reports, though right now our dev focus is on
the ipython1/0 merge for a release. But having the bugs filed will
ensure that we get to it later.
Personally, I do use the embedded shell a lot, but when I do so I call
it in standalone scripts. For quick and dirty inspection of the
internal state of a script, I often just put
and call %debug afterwards. This is post-mortem only, but often tells
me what I need to know.
I'm sorry to not give you a better solution, I'm just trying to
suggest some workflow alternatives that may give you what you need
while the above bugs get fixed (which given the available resources,
may not be right away).
More information about the IPython-user