Heads up: change to exception handling opcodes in CPython 3.8

[ncoghlan]

CPython currently relies heavily on eval loop magic to handle unwinding the stack after exceptions and other operations. This complexity then gets inherited by other eval loop implementations that rely on the CPython compiler as a front-end.

For CPython 3.7, it currently seems likely that we're going to shift more of the work into the compiler, such that the stack unwinding is explicit in the bytecode, and the eval loop no longer needs to manage that state separately from the opcode evaluation sequence.

https://bugs.python.org/issue17611 and https://github.com/python/cpython/pull/4682/files have more details on the expected change.

(This would presumably affect VOC in addition to Batavia)

[freakboy3742]

Thanks for the heads up, Nick.

On a side note, it's possible this might (eventually) become a moot point; we're doing some initial exploration on whether we can compile direct to WASM using the same approach VOC takes. This should result in a speed bump, more shared code between the the two projects, and remove the fragility caused by depending on bytecode format.

[ncoghlan]

This didn't land in 3.7, but it has landed for 3.8: https://github.com/python/cpython/pull/5006/files

It doesn't affect the AST though, only the interpreted opcode format, so if Batavia has switched to working at the AST level, then you can just close this.

[freakboy3742]

Thanks for the heads up, @ncoghlan. We haven't moved to anything AST based yet - I did some initial exploration, and it appears WASM isn't quite ready for dynamic languages (yet). It might be on the 3.8 release timeframe, however - we'll have to revisit this in a bit.