Hey Johannes,
> I'm not familiar with the pyc format so I cannot tell what the bits that
> differ mean but maybe somebody who can, can figure this out given the
> hexdump difference from above.
As I understand it, a .pyc file consists of .pyc-specific header but
the bulk of the file is "just" a marshalled PyCode object. The hexdump
you referenced has the change within this marshalled part. When I
disassemble this part using the dis module, there is no "semantic"
difference between two different .pyc files from your loop:
1 0 LOAD_NAME 0 (_m)
2 POP_TOP
4 LOAD_CONST 0 (None)
6 RETURN_VALUE
<conjectures>
This suggests that the difference is some internal implementation
detail of the marshalled PyCode object which does not affect its
execution semantics. I could imagine that some kind of string
internalisation algorithm is resulting in nondeterministic hashmap
entry numbers... or something. Still, it might not even be an
implementation detail: it could merely be uninitialised memory that is
happily skipped over by the parser.
</conjectures>
As it happens, I don't think you are the first to discover the
peculiarity of "_m" — take a look at this enigmatic comment:
https://github.com/python/cpython/issues/78903#issuecomment-1093799639
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org 🍥 chris-lamb.co.uk
`-
