5 ms·

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?

• nomel 6y ago
  What is this “compile time” you speak of?
  • pansa2 6y ago
    When the Python source code is compiled into bytecode.
    • nomel 6y ago
      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.
• mark-r 6y ago
  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.
  • owl57 6y ago
    What's the problem with ternaries?
    • mark-r 6y ago
      One of the two possible sub-expressions isn't used.
      • mkl 6y ago
        It's also not evaluated. There is no discarding, so there would be no problem.
  • dragonwriter 6y ago
    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.