Possible "hysteresis" in bytecode recompilation with 3.12 about bytecode HOT 7 OPEN

With

            for k in dir(stuff.modulestuff.__code__):
                if k.startswith("co_"):
                    print(k, getattr(stuff.modulestuff.__code__, k) == getattr(code, k))

we get

co_argcount True
co_cellvars True
co_code True
co_consts True
co_exceptiontable True
co_filename True
co_firstlineno True
co_flags True
co_freevars True
co_kwonlyargcount True
co_lines False
co_linetable True
co_lnotab True
co_name True
co_names True
co_nlocals True
co_positions False
co_posonlyargcount True
co_qualname True
co_stacksize True
co_varnames True

which might narrow it down to just co_lines and co_positions. These differ because are bound methods. Their return values seem to coincide too.

from bytecode.

Can you confirm if this is a real issue or not ?

from bytecode.

It depends on what we mean by "issue". We have round-trip tests that take a CodeType object from a function, add some extra bytecode in different order and places, then take it off, and rebuild a CodeType object. Up until CPython 3.11 we get equal CodeType objects (but not identical, because they are indeed different objects). With CPython 3.12, the equality checks fail, which is a bit of a concern. There is no evidence, however, that the new CodeType object is "functionally" different from the original.

from bytecode.

Ok. It is just that from the list you made in your previous comment the code object did look equal and that got me confused. I guess one would have to check the implementation of __eq__ on CodeType to know why it changed between 3.11 and 3.12.

from bytecode.

@P403n1x87 is this still an actual issue ?

from bytecode.

ping @P403n1x87

from bytecode.

Sorry for the late reply. Because I have disabled the "round-trip" tests I don't know if the issue has been solved. I don't think I'll be able to look back at this any time soon unfortunately 🙁 .

from bytecode.