A.3 Unsupported Python constructs
The following constructs are not supported by Psyco. It does not mean that code containing them will fail; it merely means that any function using them cannot be compiled, and will thus be entierely run by the standard interpreter.
- "from xx import *"
- the
exec
statement -- in some cases you can use eval and/or compile instead, under the restrictions described in section A.2
- all top-level module code (including e.g. test scripts run from the command-line): all code to accelerate should be inside functions. (Support for top-level module code is possible but disabled by default in recent versions of Psyco; contact me for more information.)
- the code defining a classA.1
- functions with free or cell vars, which occur with Python's new nested scopes (as enabled by "from __future__ import nested_scopes"); this concerns both the function whose local variable is made visible to a subfunction, and the subfunction using such a local variable
- generators
- generator expressions (Python 2.4). Warning! The function containing generator expressions will be compiled by Psyco, but not the generator expression itself. If the latter calls other functions compiled by Psyco, then performance will be very bad: calling from Psyco to Python to Psyco comes with a significant overhead.
Log files report unsupported constructs by giving the corresponding bytecode instruction number, which you can look up in the following table:
82 |
LOAD_LOCALS |
(1) class definitions |
84 |
IMPORT_STAR |
(5) from xx import * |
85 |
EXEC_STMT |
(2) exec xx |
86 |
YIELD_VALUE |
(3) generators |
90 |
STORE_NAME |
(5) outside functions |
91 |
DELETE_NAME |
(5) outside functions |
101 |
LOAD_NAME |
(5) outside functions |
134 |
MAKE_CLOSURE |
(4) nested scopes |
135 |
LOAD_CLOSURE |
(4) nested scopes |
136 |
LOAD_DEREF |
(4) nested scopes |
137 |
STORE_DEREF |
(4) nested scopes |
Notes:
- (1)
- Psyco cannot accelerate class definitions, i.e. the execution of the body of the class statement - i.e. the creation of the class object itself. This does not prevent it from accelerating methods in the class.
- (2)
- Functions using this construct cannot be accelerated.
- (3)
- Generators (i.e. any function using the
yield
keyword) cannot be accelerated currently. If there is enough interest I can consider implementing them.
- (4)
- Using nested scopes (i.e. variables shared by a function and an inner sub-function) will prevent both the outer and the inner function to be accelerated. This too could be worked around if there is enough interest, at least for accelerating the unrelated parts of the functions - the accesses to the shared variables themselves might be difficult to optimize.
- (5)
- These constructs can appear in class definitions or at the module top-level. It is possible to enable support for module top-level code, but not recommended; instead, try to put all the code you want accelerated in function bodies.
Footnotes
- ... classA.1
- The methods themselves are fine; this only concerns the code that runs in order to define the class (generally only a bunch of
def
statements)