EXTENDED_ARG_QUICK is a problematic opcode, and I think we should expose it less than we currently do. It is the only "quickened" opcode emitted by the compiler and found incode.co_code, which requires us to jump through strange hoops in several places (I'm looking at you,_PyOpcode_Original). Even weirder, it traces asEXTENDED_ARG at runtime.

• it's not documented anywhere in thedis documentation
• it's not even a "real" opcode exposed by any of the helpers in theopcode module (which still defines a misleadingly uselessEXTENDED_ARG constant)
• it's less thanHAVE_ARGUMENT, even though it (obviously) uses its argument
• it's not understood by things likestack_effect

Yet consumers of the bytecodemust handle it correctly. We've already seen several bugs in CPython wherewe wrongly thought that we were handling extended arguments, and code that's been unchanged for years silently stopped working correctly. Let's avoid putting user code through the same pain.

I propose that we only emit the normalEXTENDED_ARG in the compiler, like we always have, and use_PyOpcode_Deopt everywhere that_PyOpcode_Original is being used now. We'll quickenEXTENDED_ARG toEXTENDED_ARG_QUICK just like all of the other*_QUICK opcode variants. No need to change the magic number or anything, since old code will continue to work fine. AlthoughEXTENDED_ARG is in theory atiny bit slower (it deopts the next opcode using_PyOpcode_Deopt), I doubt this is actually measurable.

Thoughts? I really think we should try to do this in 3.11, since it's a relatively simple change.

CC@markshannon,@sweeneyde,@pablogsal