[IPython-user] Problem with IPShellEmbed

[Michael Foord]

Armin has replied with an alternative hack (for me only, not for IPython 
I'm afraid) :

def fullon():
    try:
        return __in_psyco__    # psyco creates a new builtin for functions it binds
    except NameError:   # Psyco was not imported
        return False



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.

Regards,


Fuzzy
http://www.voidspace.org.uk/python/index.shtml



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 
>> ptest2.py
>> 2.37400007248
>> Movable Python
>> IPython Interactive Shell. See the manual for a list of features and 
>> tips.
>> 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 
> 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.
>
> Cheers,
>
> f
>
>
>