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 and traceback objects are only partially visible to Python code. If you use functions like sys._getframe to obtain a frame object that corresponds to a Psyco-accelerated frame, some of its fields will be empty, most notably f_locals and f_back. Actually, only the f_code and f_globals fields are well-tested.
- 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).