• sugar_in_your_tea@sh.itjust.works
    link
    fedilink
    arrow-up
    4
    ·
    edit-2
    15 hours ago

    Even so, not x is a pretty nice-to-read pattern, and it’s nice that it’s faster than the less nice len(x) == 0. I generally do not care to distinguish whether a list is None or empty, I just want to know if there’s something there. If I care, then I’ll typically separate those checks anyway: if x is None: ..., if len(x) == 0: ....

    • Dark Arc@social.packetloss.gg
      link
      fedilink
      English
      arrow-up
      4
      ·
      15 hours ago

      I prefer the clarity of len(x) == 0 personally; it’s a pretty low syntactic penalty to clarify intent.

      Obviously, if your variable names are good and you’re consistent about your usage not list can be fine too, but it is a very JavaScript-y thing to me to be that vague and/or rely on “truthiness.”

      • sugar_in_your_tea@sh.itjust.works
        link
        fedilink
        arrow-up
        4
        arrow-down
        2
        ·
        15 hours ago

        The notion of truthiness is defined by the language.

        Here are most of the built-in objects considered false:

        • constants defined to be false: None and False
        • zero of any numeric type: 0, 0.0, 0j, Decimal(0), Fraction(0, 1)
        • empty sequences and collections: ‘’, (), [], {}, set(), range(0)

        It’s not something that happens to work, it’s literally defined that way.

        if not x is the common way to tell if you have data or not, and in most cases, the difference between None and empty data ([], {}, etc) isn’t important.

        len(x) == 0 will raise an exception if you give it None, and that’s usually not what you want. So I guess the verbose way to do that is if x is None or len(x) == 0:, but that’s exactly equivalent to if not x, with the small caveat that it doesn’t check if the value has __len__ implemented. If you’re getting wonky types thrown around (i.e. getting a class instance when expecting a list), you have bigger problems.

        I use type hinting on pretty much all “public” methods and functions, and many of my “private” methods and functions as well. As such, sending the wrong types is incredibly unlikely, so not x is more than sufficient and clearly indicates intent (do I have data?).

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

            It’s only vague if coming from a language where it’s invalid or vague semantically. For example:

            • Javascript - [] is truthy for whatever reason
            • C - int x[] = {}; evaluates to true because it’s a pointer; C only evaluates to false if something is 0
            • Rust - invalid because you cannot convert a vec -> bool directly, and there’s no concept of null (same w/ Go, but Go has nil, but requires explicit checks)
            • Lua - empty tables, zero, and empty strings are truthy; basically, it’s truthy unless it’s nil or false

            The only surprising one here is Javascript. I argue Lua and Python make sense for the same reason, Lua just decided to evaluate truthiness based on whether the variable is set, whereas Python decided to evaluate it based on the contents of the variable. I prefer the Python approach here, but I prefer Lua as a language generally (love the simplicity).