A.1 Known bugs
Apart from speed, functions are supposed to run identically under Psyco and under Python, with the following known exceptions:
- No locals dictionary is available. The locals function always return an empty dictionary (and issues a warning). This also affects eval, execfile, vars, dir and input unless you supply an explicit dictionary for the locals. See section A.2.
- 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.
- The compiled machine code does not include the regular polling done by Python, meaning that a KeyboardInterrupt will not be detected before execution comes back to the regular Python interpreter. Your program cannot be interrupted if caught into an infinite Psyco-compiled loop. (This could be fixed if requested.)
At other points, Psyco makes assumptions that may be wrong (and will cause damage if they turn out to be):
- Built-ins are assumed never to change. Global variables can change, of course, but you must not add or remove a global variable to shadow or expose a built-in (at least not after a module is initialized).
- Python 2.2 and later only: do not dynamically change the methods of the new-style classes (classes that inherit from a built-in type).
- Do not use Psyco together with restricted execution (the rexec module).
Some minor points:
- The error message coming with exceptions will occasionally differ from Python's (but not the exception class).
- The
is
operator might occasionally work unexpectedly on immutable built-in objects across function calls. For example, in
def save(x):
global g
g = x
def test(i):
n = i+1
save(n)
return n is g
there is no guarantee with Psyco that the integer object stored in g is identical to the object seen as n by the operator is
(althought they would of course be equal). Well, is
is not supposed to be too useful for immutable objects anyway. There are interesting exceptions, but these work as expected. Consider the above test function as broken because it should be (but is not) equivalent to
def test(i):
f(i+1)
return (i+1) is g
- I did not test these artificial examples of tricky code accessing a list while it is being sorted. The potential problem here is that Psyco assumes that the type of an object never changes, while Python (before 2.3) changes the type of the list to make it immutable during the sort.
- Running out of memory during compilation is hard to recover from. I made it a fatal error.
- Occasionally, objects become immortal. An example of such a situation that comes in mind is the initial value of a then-changing global variable. In general, however, this concerns objects that are immortal anyway (like a global variable that does not change or constants in the code).