EXTENDED_ARG 0 retained from input raises ValueError about bytecode HOT 7 CLOSED

Thanks for pointing this issue. I will try to think about it. I would prefer a solution that would allow to treat all EXTENDED_ARG on the same footing. Ping me if I do not answer in a week.

from bytecode.

Not all EXTENDED_ARG 0 are useless. For example LOAD_CONST referring to the constant number 0x10000 has two EXTENDED_ARG prefixes, one of them with argument 0.

from bytecode.

Thanks for pointing this out @serhiy-storchaka. I will keep this in mind.

from bytecode.

@serhiy-storchaka I noticed that in some cases CPython can emit EXTENDED_ARG 0 for arguments that actually are not too large to fit in the following opcode argument. Could you point me at where this might be happening in CPython source ? To me it looks like a bug.

from bytecode.

The only place I have found in peephole.c. And it is even mentioned in a comment. This is not a bug, but just the lack of optimization of this rare case.

from bytecode.

OK, I wish I had known this could happen. Thanks for looking this up @serhiy-storchaka.

from bytecode.

@serhiy-storchaka yes but in this case it is a leading EXTENDED_ARG 0. The example you point out of EXTENDED_ARG 0 following an initial non-0 is already property handled.

from bytecode.