The opcode module contains several collections:

`cmp_op`
`hasconst`
`hasname`
`hasjrel`
...

which are only used for `in` checks. At the same time, they are stored as `list`s and `cmp_op` as tuple. Both these types are not optimal for `__contains__` checks. Maybe it is worth at least to convert them to `frozenset` type after they are filled?

This list are short. I don't think there is a large benefit of this change. But there is a small risk of breaking a third party code (for example hasjrel+hasjabs).

Small risk of breaking is a fair point (maybe some FutureWarning with new __getattr__ PEP 562?). I've checked several packages:

---
vstinner/bytecode:: uses:

@staticmethod
    def _has_jump(opcode):
        return (opcode in _opcode.hasjrel
                or opcode in _opcode.hasjabs)

---
maynard:: defines them as sets and does not rely on opcode module.

all_jumps = absolute_jumps | relative_jumps

---
numba:: converts them to frozensets:

JREL_OPS = frozenset(dis.hasjrel)
JABS_OPS = frozenset(dis.hasjabs)
JUMP_OPS = JREL_OPS | JABS_OPS

---
codetransfromer:: uses:

absjmp = opcode in hasjabs
reljmp = opcode in hasjrel

---
anotherassembler.py:: uses

elif opcode in hasjrel or opcode in hasjabs:

---
byteplay:: converts them to set:

hasjrel = set(Opcode(x) for x in opcode.hasjrel)
hasjabs = set(Opcode(x) for x in opcode.hasjabs)
hasjump = hasjrel.union(hasjabs)

---
byterun:: uses:

elif byteCode in dis.hasjrel:
    arg = f.f_lasti + intArg
elif byteCode in dis.hasjabs:
    arg = intArg

In fact, all of the above indicated does not mean anything, but I have not found cases of hasjrel+hasjabs.

Despite the fact that they are small, on average, with sets I gain 5-6x speed-up.

I apologize for FutureWarning and __getattr__. I myself do not understand what I meant and how it will help in this situation :)

Maynard is unsupported; it only understands the old bytecode format, pre-3.6 16-bit "wordcode".

https://docs.python.org/3.6/whatsnew/3.6.html#optimizations

+1 for switching to sets or frozensets.