[IPython-user] Problem with IPShellEmbed

[Fernando Perez]

mike at pcblokes.com wrote:

> Right... I'm afraid stack frames are still a deeply black art to me.
> 
> Perhaps a better solution would be to put IPython in a 'Psyco proof bubble' ?
> Surely IPython doesn't go deeper into the stack than the function/scope that
> *called* IPython. So long as the locals are available from this frame we should
> be alright ?
> 
> So if you can guarantee (by hook or by crook) that we can access that frame ok
> everything is fine ? I'm probably being naive of course.......

The problem is that an ipython user can request information about a psyco-ized 
object, whose stack is unavailable.

I had a look at the embedding calls, and it would be easy to change the code 
to avoid the _getframe() calls IF you call it with a locals/globals pair of 
dicts.  In iplib.py, around line 1066, change the version I put up yesterday 
with this:

         # Get locals and globals from caller
         if local_ns is None or global_ns is None:
             call_frame = sys._getframe(stack_depth).f_back

             if local_ns is None:
                 local_ns = call_frame.f_locals
             if global_ns is None:
                 global_ns = call_frame.f_globals


This will avoid the _getframe call IF you provide BOTH a locals and a globals 
dict.  In this case, users will NOT be able to call the embedded instance with 
a simple

ipshell()

since they will HAVE to give ipython something to go with as a namespace.  So 
the call will have to be:

ipshell(local_ns=localdict,global_ns=globaldict)

or positionally:

ipshell('header string',localdict,globaldict)


> Psyco is a common tool, so it would be *better* if IPython could work with it
> (or at least around it). If there are any changes to psyco that would help this
> then I'm sure Armin would be willing to consider them.

I agree, and I'd like to play nice with psyco.  But I hope you realize that 
embedding a live interpreter into a function where psyco has explicitly 
destroyed the stack is not exactly easy :)

Cheers,

f