3 ms·

Then I guess the related question is: is this safe to use with Python implementations other than the main one (CPython)? For example, PyPy or Nuitka, neither of

• masklinn 5y ago
  > Then I guess the related question is: is this safe to use with Python implementations other than the main one (CPython)? Absolutely not. > For example, PyPy or Nuitka, neither of which use byte code (or at least I don't think so)? pypy absolutely uses bytecode. Though not necessarily cpython's bytecode (although I'd expect they have at least a bridge for cpython compatibility). Jitting straight from the source is pretty rare and tends to be avoided: it means either you don't have a baseline interpreter, or that you're repeating the work of the interpreter in your JIT, or possibly that you're interpreting and jitting from the AST. The former is what Chrome did at the start, it had a baseline compiler and an optimising compiler, which was pretty weird. After a while a baseline interpreter (ignition) was introduced, and the bytecode it generated got fed into the optimising compiler. Its timeline was a bit odd because rather than building a bytecode interpreter then building a jit for that bytecode they actually started with a bytecode-based JIT (turbofan) then figured they could interpret the bytecode directly instead of having to deal with (and patch) code from the baseline compiler, so the interpreter (ignition) grew from the effort of building a new compiler, rather than the compiler being built for the interpreter. As for AST interpretation I know it's pretty common for teaching / learning but I don't know if there's any system actually doing it for real "in production", the amount of pointer chasing seems like it'd be ridiculously inefficient.