Remove `DELETE_FAST` bytecode instruction

[markshannon]

DELETE_FAST has two uses:

1. delete var where var is a local variable
2. Cleaning up at the end of a named exception block.

A local variable can be deleted with the sequence PUSH_NULL; STORE_FAST var.

Deleting a local variable

Instead of DELETE_FAST n we can emit LOAD_FAST n; POP_TOP n; PUSH_NULL; STORE_FAST n which the bytecode optimizer will reduce to PUSH_NULL; STORE_FAST n in most cases.

Cleaning up at the end of a named exception block.

We currently emit the sequence: LOAD_CONST None; STORE_FAST n; DELETE_FAST n
which can be replaced with PUSH_NULL; STORE_FAST n

This case is far more common than explicitly deleting a local variable, so we can reduce code size as well as freeing up an opcode.

---

See faster-cpython/ideas#490

Linked PRs

• gh-145749: Optimize named exception blocks #145983

[brijkapadia]

I would like to work on this.

[brijkapadia]

Also, for the case of deleting a local variable, should DELETE_FAST n use a LOAD_FAST_CHECK n (as opposed to a LOAD_FAST n) so that del var will continue to raise an UnboundLocalError?

[markshannon]

The bytecode compiler inserts LOAD_FAST_CHECK as needed. Just use LOAD_FAST and let compiler fix it up.

[brijkapadia]

I created PR #145983 for the second problem about cleaning up named exception blocks. However, I realized that it would be best to resolve Issues #145857 and #145854 first, as there are some cases where a named exception block leads to a STORE_NAME or STORE_GLOBAL:

STORE_NAME example

try:
    1/0
except ZeroDivisionError as x:
    pass

STORE_GLOBAL example

def f():
    global x
    try:
        1/0
    except ZeroDivisionError as x:
        pass

Thus, I am putting on hold PR #145983 until STORE_NAME and STORE_GLOBAL can handle NULL values.