• Because I have to do the is this falsy to what I’m actually interested conversion in my head.

    Say ur deep inside some complicated piece of logic and u are trying to understand. Now u have a bunch of assumptions in your head. You should be trying to eliminate as many if these assumptions with good code as possible eg u test ur fail case and return/continue that so u don’t need to keep that assumption in ur head.

    Say I then come along a if not x then you have to figure out what is x what is the truthiness of its type. If I come across an if len(x) == 0 then I automatically know that x is some collection of objects and I’m testing its emptiness.

    • sugar_in_your_tea@sh.itjust.works
      link
      fedilink
      arrow-up
      1
      arrow-down
      1
      ·
      14 hours ago

      That’s why there’s type hinting, unit tests, and doc strings. I don’t need to guess what the type is intended to be, I can see it.

        • sugar_in_your_tea@sh.itjust.works
          link
          fedilink
          arrow-up
          1
          ·
          6 hours ago

          What’s the extra logic?

          if x:
          

          This always evaluates to True if it’s non-empty. There’s no extra logic.

          If you have to keep 12 things in your head, your code is poorly structured/documented. A given function should be simple, making it plainly obvious what it’s intended to do. Use type hints to specify what a variable should be, and use static analysis to catch most deviations. The more you trust your tools, the more assumptions you can safely make.