reason why there is no "if Empty" in python

Question

the zen of python says "Explicit is better than implicit."

i find that an is Empty to check whether some sequence is empty is so much more explicit than implicit booleanness

if some_sequence is Empty:
  some_sequence.fill_sequence()

compare with

if not some_sequence:
  some_sequence.fill_sequence()

this gets even more confusing with some unfavorably choosen variable names

if saved:
  mess_up()

compare with

if saved is not Empty:
  mess_up()

see also: http://stackoverflow.com/questions/53513/python-what-is-the-best-way-to-check-if-a-list-is-empty i find it ironic that the most voted answer claims that implicit is pythonic.

so is there a higher reason why there is no is Empty in python?

Answer 1

Polymorphism in if foo: and if not foo: isn't a violation of "implicit vs explicit": it explicitly delegates to the object being checked the task of knowing whether it's true or false. What that means (and how best to check it) obviously does and must depend on the object's type, so the style guide mandates the delegation -- having application-level code arrogantly asserts it knows better than the object would be the height of folly.

Moreover, X is Whatever always, invariably means that X is exactly the same object as Whatever. Making a totally unique exception for Empty or any other specific value of Whatever would be absurd -- hard to imagine a more unPythonic approach. And "being exactly the same object" is obviously transitive -- so you could never any more have distinct empty lists, empty sets, empty dicts... congratulations, you've just designed a completely unusable and useless language, where every empty container crazily "collapses" to a single empty container object (just imagine the fun when somebody tries to mutate an empty container...?!).

Answer 2

I agree that sometimes if foo: isn't explicit for me when I really want to tell the reader of the code that it's emptiness I'm testing. In those cases, I use if len(foo):. Explicit enough.

I 100% agree with Alex w.r.t is Empty being unpythonic.

Answer 3

Consider that Lisp has been using () empty list or its symbol NIL quite some years as False and T or anything not NIL as True, but generally computation of Truth already produced some useful result that need not be reproduce if needed. Look also partition method of strings, where middle result works very nicely as while control with the non-empty is True convention.

I try generally avoid using of len as it is most times very expensive in tight loops. It is often worth while to update length value of result in program logic instead of recalculating length.

For me I would prefer Python to have False as () or [] instead of 0, but that is how it is. Then it would be more natural to use not [] as not empty. But now () is not [] is True so you could use:

emptyset = set([])    
if myset == emptyset:

If you want to be explicit of the empty set case (not myset is set([]))

I myself quite like the if not myset as my commenter.

Now came to my mind that maybe this is closest to explicit not_empty:

if any(x in myset for x in myset): print "set is not empty"

and so is empty would be:

if not any(x in myset for x in myset): print "set is empty"