Opcode 69:GET_YIELD_FROM_ITER not implemented

[freakboy3742]

PR #592 added support for yield from; however, because we didn't have CI set up for Python 3.5, we didn't pick up that the GET_YIELD_FROM_ITER opcode hasn't been implemented.

Problem is revealed pretty quickly if you uncomment the Python 3.5 build target for Beekeeper.

[freakboy3742]

Pinging @abonie because it's on his turf :-)

[abonie]

I'm on it 👍

[abonie]

Related question: How do we want to handle supporting different Python versions in parallel? In this case I could define opcode 69 in dis module and since it is not used in Python 3.4, the only downside is that dis.opname[69] will return different results in CPython 3.4 and Batavia with Python 3.4 bytecode. However it gets more complicated when same opcode has different names across versions. If we could have different dis modules and choose one depending on the bytecode version, it would solve part of the problem. But I am not sure how to do this, AFAIK at the very least it would require delaying building dispatch table in VM until after bytecode is loaded, so that Python version is already known.
@freakboy3742 ?

[abonie]

#599 fixes this issue, but I took the path of least resistance in solving above mentioned problem. I'll change it once we establish the best way to deal with opcode discrepancies between versions.

[freakboy3742]

I'm happy to address this at runtime, much as you've done with WITH_CLEANUP. dis.opname[69] should never be invoked on Python 3.4, so there's no real harm in having that code in the table, but in the case of a Python 3.4 opcode being altered, we can check at runtime if we're in Python 3.4 or 3.X.

Longer term, I would like to move to a model where we have a 3.4 branch, and 3.5 branch, and so on, so each branch only has to support one version of Python. However, until such time as we have good coverage of at least one version of Python, this is more effort than it's worth.