@gvanrossum cc @markshannon

I updated the code_richcompare not to modify the code object at all.

Would it better to ignore co_code_adaptive, and use co_code for comparisons?
It will definitely be slower, but it will be correct.

Ultimately we will want to compare by identity, I think.

Ultimately we will want to compare by identity, I think.

I'm no so sure, I expect that would cause too much breakage.

Would it better to ignore co_code_adaptive, and use co_code for comparisons?

Or factor out the normalization code involved in constructing co_code so it can be reused by compare and hash.

Would it better to ignore co_code_adaptive, and use co_code for comparisons?

Or factor out the normalization code involved in constructing co_code so it can be reused by compare and hash.

Never mind, that's already factored out (deopt_code()) but it modifies the bytecode array in place.

We keep changing the hash and equality functions, so I don't really see how another change will break anything, apart from assumptions in the compiler.

Would it better to ignore co_code_adaptive, and use co_code for comparisons?
It will definitely be slower, but it will be correct.

IIUC, we need to update _PyCode_CODE for comparisons or add a new macro. It's worth experimenting with it.
I would like to do it in separate PR including the performance overhead comparison.

We keep changing the hash and equality functions, so I don't really see how another change will break anything, apart from assumptions in the compiler.

It seems pretty fundamental that co == co.replace(), which comparing by identity would break (and we rely in many places on .replace() always creating a new code object, with no specializations or executors, and all caches reset). IMO any field that can be changed through code.replace(xxx=yyy) should be included in equality, and no others. The hash should use a pragmatic subset of these that satisfies the required relationship between hash and equality and can be computed quickly.

In #101346 I tried to change code objects to compare by identity, and in the process I reached the same conclusion as @gvanrossum.

Making co != co.replace() (or, similarly, compile(source_string, ...) != compile(source_string, ...)) is a much bigger change than any tweaks to the details of code object comparison that have happened up until now.