Support general constants

Hello, I’ve found that the code object could not take unhashable object as its co_consts, for you use a dictionary to store the constants. I think that we may not follow the implementation of _PyCode_ConstantKey for further usage. Actually my project needs making more kinds of constants than CPython already has. https://github.com/vstinner/bytecode/blob/a7cc7a52ca10e58a8aee48052edd069fac3c5a01/bytecode/concrete.py#L439

    self.consts = {}
    ...
    def add_const(self, value):
        key = const_key(value)
        if key in self.consts:
            return self.consts[key]
        index = len(self.consts)
        self.consts[key] = index
        return index

Could we add a compiler flag to support unhashable constants? Just consider using associate list (List[Tuple[K, V]]) to store unhashable ones.

[MatthieuDartiailh]

Sorry for delay.

@SnoopyLane I must say I am quite convinced by your argument. So I believe too now that this should be allowed. However, since we generate the keys in the dictionary ourselves, I believe it would be simpler (ie less maintenance) to simply generate valid keys and keep a simple dictionary. In particular, when comparing the key generation algorithm to the current CPython trunk it seems to me it changed a bit since 3.6 (but I may be wrong).

I must also admit that at first it was not clear that this would even generate valid CPython, but now that @thautwarm implementation proves it works, I am good with it.

[SnoopyLane]

I have mixed feelings about the proposed change.

I agree that it’s abusing the const-ness of things. If anything, in optimizers that I’ve built I have sometimes been unsure of what would be well-behaved as far as CPython is concerned. In other words, “Is this optimization actually legitimate, does it maintain 100% of the subtle details and contracts of CPython and not introduce any new ones?” I’ve got some rewrite-rules for folding constants and I actually call hash© on a value: if it isn’t hashable then I fail my “is it a foldable constant?” test.

On the other hand, bytecode isn’t used by normal people. Its use can be analogous to dropping down to assembler when you just cannot express something in C/C++/whatever. It would make no sense for assembler to fail with an error message “That wouldn’t be valid C behavior”, since that’s the whole reason you’re using assembler in the first place.

I think what I’ve just talked myself into the following proposal: Let the bytecode library support construction of valid bytecodes, even if that means the result is not valid Python.

Edit: If not clear, outside of code review issues, I’m for thautwarm’s proposal, even if his/her immediate problem could be solved in other ways.