On: The PEPs of Python 3.9

[BiteCode_dev]

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?