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 `-