3 ms·
Reply from the email thread: When I disassemble this part using the dis module, there is no "semantic" difference between two different .pyc fil
by version_five 5y ago
Reply from the email thread:
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.
It goes on to show another minimal example where this happens. Is there some claim or specification that compilation will be deterministic?
- bcrl 5y agoCan someone please explain why this is? It looks like black magic to me.
- rurban 5y agoBecause _m is referenced in types, m not, so the compiler adds a referenced flag to _m. And this reference is looked up via a compile-time hash, hence the non-determinism. just guessing though, I'm a perl expert, not python.
- pabs3 5y agoNo, but the bug was filed by the Reproducible Builds team, who aim to make all builds deterministic, including builds of OS images, which can contain .pyc files. https://reproducible-builds.org/ https://reproducible-builds.org/