Yea and then you use “not” with a variable name that does not make it obvious that it is a list and another person who reads the code thinks it is a bool. Hell a couple of months later you yourself wont even understand that it is a list. You should not sacrifice code readability for over optimization, this is phyton after all I don’t think list lengths will be your bottle neck.

That’s why we use type-hinting at my company:

def do_work(foo: list | None): if not foo: return ...

Boom, self-documenting, faster, and very simple.

len(foo) == 0 also doesn’t imply it’s a list, it could be a dict or any other type that implements the __len__. That matters a lot in most cases, so I highly recommend using type hints instead of relying on assumptions like len(foo) == 0 is probably a list operation.

Well, in your case it is not clear whether you intended to branch in the variable foo being None, or on the list being empty which is semantically very different…

Thats why it’s better to explicitelly express whether you want an empty collection (len = 0) or a None value.

Well yeah, because I’m explicitly not defining a difference between None and []. In most cases, the difference doesn’t matter.

If I did want to differentiate, I’d use another if block:

if foo is None: ... if not foo: ...

Explicit is better than implicit. I hate relying on exceptions like len(foo) == 0 raising a TypeError because that’s very much not explicit.

Exceptions should be for exceptional cases, as in, things that aren’t expected. If it is expected, make an explicit check for it.

I don’t really understand the point about exceptions. Yeah “not foo” cannot throw an exception. But the program should crash if an invalid input is provided. If the function expects an optional[list] it should be provided with either a list or None, nothing else.

Sure. But is None invalid input in your case, whereas [] is valid? If so, make that check explicit, don’t rely on an implicit check that len(…) does.

When I see TypeError in the logs, I assume the developer screwed up. When I see ValueError in the logs, I assume the user screwed up. Ideally, TypeError should never happen, and every case where it could happen should transform it to another type of exception that indicates where the error actually lies.

The only exceptions I want to see in my code are:

• exceptions from libraries, such as databases and whatnot, when I do something invalid
• explicitly raised exceptions

Implicit ones like accessing attributes on None or calling methods that don’t exist shouldn’t be happening in production code.

I agree. So if None is a valid input we should check it first, and then check if the length is zero. In this situation, we see a type error only if the programmer screwed up and everything is explicit

Yes. If None is just as valid and has the same meaning as [] for the function (true more often than not), just do if not foo. If None should be handled separately from [] for some reason, treat them both separately so it’s absolutely clear.

Explicit is better than implicit.
Errors should never pass silently.

And I especially like this one:

That said, jihadists are a subset of Nazis, just a not very stereotypical one for a westerner.

There should be one-- and preferably only one --obvious way to do it

The one obvious way to check if you have data is if foo. That works for pretty much everything as you’d expect. Explicitly deviating from that is a cue to the reader that they should pay attention. In this case, that means None is semantically different than empty data, and that’s something the reader should be aware of because that’s usually not the case.

Edit: Oops, horrendous copy buffer issue from another thread. Read stuff before you post kids, don’t be like me. 😆