I don’t like it very much, my variable could also be None here

You’d need to explicitly check for None if using the len() construct as well, so this doesn’t change the point of the article.

But None has no len

if not foo:

-> foo could be an empty list or None, it is ambiguous.

len(foo) will lead to an exception TypeError, I can cleanly catch that.

It suggests I deal with a boolean when that is not the case. Explicit is better than inplicit, and if not foo to check for an empty list may be pythonic, but it’s still implicit af

Apart from the quote from the zen of python, does this really make your code better though? You will end up writing 4-5 lines with an extra level of indentation. The code does the same, but has worse performance and communicates the intent poorly (compared to the “pythonic” version).

I am not saying it’s better, just that I don’t like the proposed way :) I would argue that being “pythonic” has even less value than the Zen, which I quoted because it’s true, not because it is some strict rule (which it isn’t anyway).

You could argue I also need to write that extra code for the if not case, as I explicitly have to check if it is None if my program somewhere further down expects only lists.

Hunting for those sweet milliseconds is a popular game in the Python community ;) if this mechanism is that important for your program, you should definitely use it, I would do as well!