This is a great example of the problem of the assumption of zero as representing false.

I’ve always been ambivalent about Python’s concept of Truthiness (“something or nothing”). If I were to write my own language, I would probably require a actual Boolean for, eg, an if statement.

The fact is that what defines falsiness is use case dependent. Numbers are the best example, zero. A often be a perfectly meaningful number.

Which id why Brandon suggested that testing the length of a sequence was a good way to be explicit about what you mean by false in a particular context.

But I see no reason to add a standardized way to check for an empty container- again “emptiness” may not be obviously defined either.

Numpy arrays, (or Pandas Dataframes) are a good example here — there are more than one way to think of them as false - but maybe more than one way to think of them as empty too:

Is a shape () (scalar) array empty ?

Or shape (100, 0) ?

Or shape (0, 100)

Or shape (0,0,0,0)

Or a rank 1 array that’s all zeros? Or all false?

Anyway, the point is that “emptiness” may be situation specific, just like truthiness is.

So explicitly specifying that you are looking for len(container) == 0 is more clear than isempty(container) would be, even if it did exist.

With duck typing, you may well not know what type you are dealing with, but you absolutely need to know how you expect that object to behave in the context of your code. So if having a zero length is meaningful in your code — then only objects with a length will work, which is just fine.

-CHB