On Mon, Apr 6, 2020 at 1:53 PM Jonathan Goble firstname.lastname@example.org wrote:
I'm getting ready to get back into an old personal project with some new ideas. Before I do, I need to ask a question regarding the stability of CPython bytecode. Before you say it, I am well aware and fully understand that the opcodes may change in value and semantics between 3.x and 3.(x+1) without notice, and that's acceptable to me.
My question is, are the opcodes guaranteed stable across the lifetime of a single 3.x release? In other words, are they guaranteed to not change values or semantics between 3.x.y and 3.x.(y+1)? Reading through the list of opcodes in the dis documentation, it seems that all changes have occurred in 3.x.0, so it seems the answer would be yes, but then the "CPython implementation detail" paragraph at the top doesn't specify that and is a little vague on whether that's true or not.
The best way to look at this is to consider how long a .pyc file is valid. They're currently named something like __pycache__/modulename.cpython-38.pyc which is a fairly clear indication that the cached compiled module should be valid for any CPython 3.8.x release. So yes, you should be safe within any given release. The reason it's a CPython implementation detail is also hinted at in the file name: if you were to use Jython or PyPy or IronPython or MicroPython or any other implementation, you can't be sure your bytecodes will work, even if the version number is the same. (An interpreter can be compatible with Python 3.8 without having the same bytecode as CPython 3.8.)
So for your purposes, it sounds like, yes, this WILL work. :)