Don't think so, Python doesn't really care if you dispose of the results of an expression. Think about the problems you'd have with ternaries.

Ternaries don't discard results that are generated, they are just special short-circuiting operators;

  x if y else z

Is effectively syntax sugar for:

  y and x or z

Nothing is discarded after evaluation, one of three arms is never evaluated, just as one of two arms of a common short-circuiting Boolean operator often (but not always) is not. That's essentially the opposite of executing and producing possible side effects and then discarding the results.

What's the problem with ternaries?

One of the two possible sub-expressions isn't used.

It's also not evaluated. There is no discarding, so there would be no problem.

What is this “compile time” you speak of?

When the Python source code is compiled into bytecode.

That byte code is then interpreted at runtime, so the meaning of s.upper() could change. What something does, when it’s parsed, is not fixed.

You can definitely catch most cases at runtime. I’ve done something like this, in an library, to catch a case where people were treating the copy of data as a mutable view.

    interface[address][slice] = new_values # fancy noop

Where a read, modify, write was required:

    byte_values = interface[address]
    byte_values[slice] = new_values
    interface[address] = byte_values

It would log/raise a useful error if the there was no assignment/passing of the return value.