checking if a list is empty

[Steven D'Aprano]

On Wed, 11 May 2011 10:02:42 +0100, Hans Georg Schaathun wrote:

> The problem with 'if x' is that it requires a much more detailed
> understanding of python.

"Much" more detailed? Hardly.

Understanding that Python accepts any and all objects in truth-testing 
concepts, and the rules thereof, is Python 101 territory. It's beginner-
level knowledge. It is far less advanced than the knowledge that ** is 
used for exponentiation. After all, many programmers have never needed to 
raise a number to a power, and might not learn about it for years, but 
every programmer writes if or while statements at some point.

Not knowing that you can write "if x" instead of "if x == []" is like not 
knowing that you can write 

    elif condition

instead of 

    else:
        if condition

If somebody were to argue that it is "better to write else if explicitly, 
instead of the confusing elif", we'd all laugh at them.

Every time the question of conditional testing comes up here, it never 
ceases to astonish me how many developers argue against learning the 
idioms of the language, and prefer to re-use the idioms of other 
languages in Python.

Python is an object-oriented language where objects get to decide for 
themselves whether they should be treated as true or false. Writing:

    if x == []:

instead of 

    if x:

merely[1] because you worry that it isn't explicit enough, or could 
confuse other developers, or out of some nagging concern that maybe 
Python will do the wrong thing[2] unless you hold its hand through the 
process, is as silly as writing this:

    count = 0
    for item in x:
        count += 1


instead of:

    count = len(x)

(As silly, but not as verbose.)

I don't mean to insult anyone, but I've heard and read all the arguments 
against Python's truth-testing, and they don't impress me in the 
slightest. Most of them strike me as silly. The only argument that 
carries any weight to me is one which I haven't seen anyone raise:

"if x:" turns something which arguably could have been a mistake ("oops, 
I forgot to write the condition!") into valid code.





[1]  It may be that there are good, solid reasons for writing explicit 
len(x)==0 tests, although I'm hard-pressed to think of any. The closest I 
come to is when you wish to emphasize "equal to some number that just 
happens to be zero" rather than "it's a false/empty value". If so, you 
get a free pass to write the test the long way. E.g. you might write 
"x % 2 == 1" rather than just "x % 2" because you want to highlight that 
the remainder equals one, rather than the remainder merely being a true 
value.


[2]  Of course, a custom object x might misbehave when you test it for 
truth value. That would be a bug, just like it would be a bug if it 
misbehaved when you call len(x) == 0. If you can't trust "if x" to work, 
what makes you think you can trust "len(x) == 0" either?


-- 
Steven