Imagine reviewing Python code that looks something like this.
has_items = items is not None and len(items) > 0 if has_items: ... ... do_stuff(has_items=has_items)
You might look at the conditional, and disapprove:
None and empty collections are both falsey, so there's no reason to define that
has_items variable; you could just say
But, wouldn't it be weird for
has_items kwarg to take a collection rather than a boolean? I think it would be weird: even if the function's internals can probably rely on mere truthiness rather than needing an actual boolean type for some reason, why leave it to chance?
So, maybe it's okay to define the
has_items variable for the sake of the function kwarg—and, having done so anyway, to use it as an
You might object further: but, but,
None and the empty collection are still both falsey. Even if we've somehow been conned into defining a whole variable, shouldn't we say
has_items = bool(items) rather than spelling out
is not None and len(items) > 0 like some rube (or Rubyist) who doesn't know Python?!
Actually—maybe not. Much of Python's seductive charm comes from its friendly readability ("executable pseudocode"): it's intuitive for
if not items to mean "if
items is empty". English, and not the formal truthiness rules, are all ye need to know. In contrast, it's only if you already know the rules that
bool(items) becomes meaningful. Since we care about good code and don't care about testing the reader's Python knowledge, spelling out
items is not None and len(items) > 0 is very arguably the right thing to do here.