• gigachad@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    15 days ago

    This is what I would come up with:

    try:
        if len(foo) == 0:
        ...
    except TypeError:
        ...
    

    There is no need to add a None check, as foo being None should be considered as a faulty input. Avoiding the possibility of foo being None from the beginning using static checks or testing is of course the preferred solution. But in reality we do not work in such optimal environments, at least I can say that from the perspective of data science, where often procedural, untested code is produced that runs only a few times. But I get your point and I think both paths are viable, but I am also okay with being in the wrong here,

    • sugar_in_your_tea@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      0
      ·
      15 days ago

      That’s terrible, and I would block that PR in a heartbeat, unless there was a very good reason for it (given context). I would instead prefer:

      if foo is None:
          ...
      

      Exceptions are useful for bubbling up errors, they’re a massive code smell if you’re catching something thrown by local logic. Just like you shouldn’t catch IndexError right after indexing a list, you shouldn’t catch TypeError right after checking the length. If you need to check parameters, check them at the start of your function and return early.