[IPython-user] Problem with IPShellEmbed
mike at pcblokes.com
Thu Feb 3 10:07:37 CST 2005
Armin has replied with an alternative hack (for me only, not for IPython
I'm afraid) :
return __in_psyco__ # psyco creates a new builtin for functions it binds
except NameError: # Psyco was not imported
If psyco.full() has been called, this function returns True, otherwise
it returns False. At least now I can tell if psyco has been called and
use the interactive interpreter from code rather than IPython.
Fernando Perez wrote:
> 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
>> Movable Python
>> IPython Interactive Shell. See the manual for a list of features and
>> Ctrl-D to exit.
>> *** ITPL FATAL ERROR ***
>> 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
>> 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