On: The PEPs of Python 3.9

[cesarb]

IMO, this is a defect in the language: the lack of a "must_use" annotation or similar. If that annotation existed, and the .upper() method was annotated with it, the compiler could warn in that situation.

[diarrhea → cesarb]

But you are free to do

  if title == user_input.upper():

That is, you convert a string to upper without binding the result to a name. You just use it in-place and discard the result, which is fine.

With compiler, you mean mypy or linters?

[TkTech → diarrhea]

That's still "using" the resulting value for a comparison. CPython isn't an optimizing compiler, or it would completely remove the call to upper().

    >>> def up(v):
    ...     v.upper()
    ...
    >>> dis.dis(up)
    2           0 LOAD_FAST                0 (v)
                2 LOAD_METHOD              0 (upper)
                4 CALL_METHOD              0
                6 POP_TOP
                8 LOAD_CONST               0 (None)
                10 RETURN_VALUE

    >>> def up(v):
    ...     if v.upper() == "HelloWorld":
    ...        return True
    ...
    >>> dis.dis(up)
    2           0 LOAD_FAST                0 (v)
                2 LOAD_METHOD              0 (upper)
                4 CALL_METHOD              0
                6 LOAD_CONST               1 ('HelloWorld')
                8 COMPARE_OP               2 (==)
                10 POP_JUMP_IF_FALSE       16

    3          12 LOAD_CONST               2 (True)
                14 RETURN_VALUE
            >>   16 LOAD_CONST               0 (None)
                18 RETURN_VALUE

Notice in the first example, right after CALL_METHOD the return value on the stack is just immediately POP'd away. The parent is saying that when you run `python example.py` CPython should see that the return value is never used and emit a warning. This would only happen because `upper()` was manually marked using the suggested `must_use` annotation.

[delaaxe → diarrhea]

He meant that writing a line of code with only contents:

    msg.upper()

should trigger a warning as this clearly doesn't do anything.

[BiteCode_dev → cesarb]

Python is interpretted, not compiled, and completly dynamic. You cannot check much statically.

In fact, any program can replace anything on the fly, and swap your string for something similar but mutable.

It's the trade off you make when choosing it.

[pansa2 → BiteCode_dev]

I agree, there’s no way to issue a warning about a bare `s.upper()` at compile time. I wonder if it would be possible at runtime?

[mark-r → pansa2]

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.

[dragonwriter → mark-r]

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.

[owl57 → mark-r]

What's the problem with ternaries?

[mark-r → owl57]

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

[mkl → mark-r]

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

[nomel → pansa2]

What is this “compile time” you speak of?

[pansa2 → nomel]

When the Python source code is compiled into bytecode.

[nomel → pansa2]

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.

[dragonwriter → BiteCode_dev]

> Python is interpretted, not compiled, and completly dynamic. You cannot check much statically.

The existence of mypy and other static type checkers for Python disproves that; given their existence, warning of an expression producing a type other than “any” or strictly “None” was used in a position where it would neither be passed to another function or assigned to a variable that is used later should be possible. Heck, you could be stricter and only allow strictly “None” in that position.

[liveoneggs → BiteCode_dev]

so what are these annoying pyc files about?