I reviewed wpy3.patch.

I concur with Raymond, it's really nice to have a regular structure for the bytecode.

--

Serhiy proposed to *reduce* the size of bytecode by adding new specialized bytecode which include the argument. For example (LOAD_CONST, 0) => LOAD_CONST_0. I would like to hear his opinion on this change.
https://mail.python.org/pipermail/python-ideas/2016-February/038276.html

Data+code loaded by import is the top #1 memory consumer on basic scripts according to tracemalloc:
https://docs.python.org/dev/library/tracemalloc.html#examples

I don't know the ratio between data and code. But here we are only talking about the co_code fields of code objects. I guess that the file size of .pyc is a good estimation.

I don't think that the memory footprint of bytecode (co_code fields of code objects) really matters on computers (and smartphones?) of 2016.

*If* I have to choose between CPU performance and memory footprint, I choose the CPU!

--

> This does _not_ include having f_lasti be -1 instead of -2

IMHO it's ok to break the C API, but I would prefer to keep the backward compatibility for the Python API (replace any negative number with -1 for the Python API).