A.1 Known bugs

Apart from speed, functions are supposed to run identically under Psyco and under Python, with the following known exceptions:

The functions locals, eval, execfile, vars, dir and input should work as expected starting from Psyco 1.3, but 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.)
Infinite recursions are not correctly detected. They are likely to result in segmentation faults (or whatever a stack overflow triggers on your system) instead of Python's nice RuntimeError. Similarily, circularities among data structures can cause troubles (e.g. printing or comparing lists that contain themselves).
In Python 2.6 parts of the warnings module were rewritten in C. As a result, the reported warnings may be misplaced (they cannot show a Psyco-compiled frame).
In Python 2.6, creating namedtuple classes (not instances) in a Psyco-optimized function gives the class the wrong __module__ attribute, for the same reason as above: it is created by C code, so it ignores the Psyco frame hooks.

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).
Do not dynamically change the methods of the new-style classes (classes that inherit from a built-in type).
Psyco assumes that types never change. This is basically wrong (you can assign to __class__). This might cause Psyco to randomly believe that instances are still of their previous type.
Do not use Psyco together with restricted execution (the rexec module). (Given that rexec is deprecated and not safe in the first place, not using it is probably a good idea anyway.)

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).