[IPython-user] Problem with IPShellEmbed

Fernando Perez Fernando.Perez at colorado.edu
Wed Feb 2 12:23:23 CST 2005

Michael Foord wrote:

> Hmmm... even with these changes I still die if 
> ``ipshell(local_ns=localdict,global_ns=globaldict)`` is called.
> I have made sure to call ``psyco.cannotcompile(interactive)`` so the 
> interactive function *shouldn't* be bound by psyco. I am explicitly 
> passing in locals() and globals() to the interactive function.
> The error I get is as follows  :
> D:\Python Projects\modules in progress\movpy\files\test>movpy.py  -i 
> ptest2.py
> 2.37400007248
> Movable Python
> IPython Interactive Shell. See the manual for a list of features and tips.
> Ctrl-D to exit.
> Invalid frame in the stack, no globals/locals available.
> Frame object: <psyco.support.PsycoFrame instance at 0x015E7828>

Well, it's as bad as I feared it would be: there are _many_ parts of ipython 
which use itpl, and it relies too heavily on stack tricks.  It may be possible 
to rewrite things to be extremely careful with this, which would help psyco 
and probably also Jython.  However, this would require a ton more work than I 
can commit to right now, as I have a number of pressing deadlines.

If you can play around with the itpl code to find out where it's causing 
trouble, and can find a solution, by all means send it my way and I'll include 
it.  But I'm really sorry to say that I can't promise a major effort coming 
from me on this right now, as much as I'd like to see the ipython+psyco 
combination behave well.

> This message just cycles until I hit ctrl-D. In this case psyco.full() 
> is not called by my script but in ptest2.py which is compiled and 
> eval'd. My problem is that I have no way of knowing whether a script we 
> run will call psyco.full() - I just have to warn my users that if they 
> call scripts that have psyco they can't use IPython. In some ways this 
> situation is worse - at least before IPython actually bombed out  (so I 
> could trap the error and do something else) !!

It's easy to undo this change, I haven't even committed it to CVS yet, waiting 
for your reports.  For now, just rip it out in your own copy and revert back 
to the old one (or use an official release, or use CVS, the only copy with 
this change was the one I put in testing for you).

> I have asked Armin Rigo for help on this - including *either* a way to 
> just apply psyco to the code object returned by compile (at the moment 
> psyco.bind(object) doesn't work with code objects) - *or* a way of 
> telling if psyco.full() has been called.
> Note the following from the psyco user guide (which might or might not 
> be helpful) :
> *Frame objects* are emulated. The sys._getframe function returns an 
> instance of a custom class which emulates the standard frame objects' 
> behavior as much as possible. The frames corresponding to a 
> Psyco-accelerated frame have some placeholder attributes, notably 
> f_locals. /There is no way to read the local variables of a 
> Psyco-accelerated frame./ Actually, only the f_code, f_globals, f_back 
> and f_lineno fields are well-tested. Also keep in mind that if you 
> obtain a real frame object (which you can do with some other mean than 
> sys._getframe, e.g. via a traceback object), the f_back chained list 
> will not include the Psyco-accelerated frames.

Actually it is.  It explains exactly the origin of the original failure: "the 
f_back chained list will not include the Psyco-accelerated frames".  This is 
why I was hitting a None object out of the blue in the stack.

His comment about the locals being inaccessible is also useful.  I suggest you 
play with Itpl, around line 177.  Disable the error I put in which is causing 
you grief, and perhaps you can find a suitable combination of return 
information which might make at least a compromise solution.



More information about the IPython-user mailing list