From: Armin R. <ar...@ul...> - 2002-03-24 14:24:25
|
Hello everybody, Just checked in the update of Psyco to a working sys._getframe(). The Psy= co package installs a new version of _getframe() into the sys module when yo= u load it (so always use sys._getframe() in your application, and don't cop= y _getframe() into your globals because you might call Python's version thi= s way). The returned frame objects are the standard one for functions that are executed by Python, but not for functions executed by Psyco. In this case the frame object is very limited (essentially only f_code and f_globals c= an be read), and you have absolutely no guarantee that each invocation of _getframe() returns the same object -- both in the sense of 'is' and '=3D= =3D' -- for the same frame. *Never Use the f_back Field*: it can contain a plain wrong value (includi= ng None). Use sys._getframe() again if you need to visit the full stack. To have it work I had to emit a few instructions (only 3, so it should no= t noticably slow things down) around each call from Psyco-compiled code to another Psyco-compiled code. This actually builds a kind of linked list i= n the machine stack. The modified _getframe() examines this linked list, interleaves real Python frames with the Psyco ones, and if the result wou= ld be a Psyco object it builds a limited Python frame object to emulate it. Maybe it would be safer to return an object of a completely different typ= e in this case, e.g. "psyco frame", that would only implement the supported portion of the Python frames; code using unsupported features would then explicitely break. A bient=F4t, Armin. |