Yes, it would mean that, which is particularly nasty considering the fact that `_` in python and `Out` in IPython would then acquire the very reference that was being deleted.
I think that my proposed change would be unacceptable without addressing this problem.

To resolve this, `del` could be made both a statement and an expression.
The parsing rules would be very similar to how the walrus operator is handled today, but instead of being a SyntaxError in statement mode, it would simply produce a different ast node:

* `del x` -> `Delete(x)`  (as `x := 0` -> SyntaxError)
* `(del x)` -> `Expr(DeleteExpr(x))`   (as `(x := 0)` -> `Expr(NamedExpr(...))`)


On Fri, 12 Jun 2020 at 17:21, Guido van Rossum <> wrote:
On Fri, Jun 12, 2020 at 4:55 AM Eric Wieser <> wrote:
> He thought that the change of del he proposed will give him that behavior, but this is not true.

Unless I'm forgetting part of the conversation, that's not true. Note that the numpy patch is merged. Today, you get the optimization with `z = a + b + c + d`. What you don't get is the same optimization if you use:
ab = a + b
abc = ab + c
z = abc + d
The language feature I propose is to allow you to _keep_ the optimization that was present in `z = a + b + c + d`, but write it as
ab = a + b
abc = (del ab) + c
z = (del abc) + d

But does that mean that typing `del x` at the REPL will print the value of `x`? That seems wrong. If `del x` is an expression that returns the value of `x` (and then unbinds it), then the REPL would seem to have no choice but to print the returned value -- the REPL has no indication that it came from `del`.

--Guido van Rossum (