treating `const_key` of a code object as mutable one about bytecode HOT 4 CLOSED

I suggest removing types.CodeType here.

from bytecode.

As the tuple and frozenset could consist of mutable data, following return (obj_type, obj, key) wouldn't work in the above case.

https://github.com/vstinner/bytecode/blob/45d643f6a706ae95586a874ea0fbcb18e797bfa1/bytecode/instr.py#L69

https://github.com/vstinner/bytecode/blob/45d643f6a706ae95586a874ea0fbcb18e797bfa1/bytecode/instr.py#L73

from bytecode.

We end up having an issue with CodeType because we allow to build weird code type that end up being unhashable which usually never happens. I am not sure what relying on id for CodeType could lead too and why CPython does not do it (an idea @serhiy-storchaka ?). Depending on the answer we may need to "legalize" the CodeType to be able to use it as key.

Regarding tuple and frozenset your argument seem valid, I would need to think more about possible corner cases. Could you make a PR in the meantime ?

For reference the current CPython implementation is here : https://github.com/python/cpython/blob/master/Objects/codeobject.c#L678

from bytecode.

I am not sure what relying on id for CodeType could lead too and why CPython does not do it

For CPython implementation, all constants can be serialized by marshal.dumps. So keeping this function simple suffices and is more efficient.

As a user of bytecode, IMO we're working with code objects and trying to do optimizations on them. Constant linking to avoid loading variables from global scope is really a huge performance gain in many cases, so it's indeed a use case.

Regarding tuple and frozenset your argument seem valid, I would need to think more about possible corner cases. Could you make a PR in the meantime ?

Yes. In fact I have come up with a proven method to implement const_key . I'll explain in the PR later.

from bytecode.