checking if a list is empty

[Steven D'Aprano]

On Wed, 11 May 2011 15:34:28 +0100, Hans Georg Schaathun wrote:

> On 11 May 2011 13:45:52 GMT, Steven D'Aprano
>   <steve+comp.lang.python at pearwood.info> wrote:
> :  Do you think that we should avoid chained comparisons, class methods,
> :  closures, co-routines, decorators, default values to functions, : 
> delegation, doc tests, exceptions, factory functions, generator : 
> expressions, inheritance, iterators, list comprehensions, operator : 
> overloading, properties, regular expressions, tuple unpacking, or unit :
>  tests, to say nothing of *advanced* techniques like descriptors or : 
> metaclasses, just in case the person reading your code is a clueless
> n00b?
> 
> Not at all.  On both accounts.
> 1. My concern was not about clueless newbies.  They need to
>   learn.  My concern is about experienced scientists and engineers who
>   are simply new to python.

Which makes them clueless newbies *about Python*. I don't care how 
experienced they are in astrophysics or biology or calculating the 
average airspeed of an unladen swallow.


>   They will be dealing with a dozen different
>   languages (programming and otherwise), with a need to read more
>   languages than they can possibly learn to master.

Yeah, life is hard and then you die, and scientists don't even get paid 
that much. So what? Do physicists write their scientific papers about 
string theory with the thought "What if some Python programmer who knows 
nothing about string theory is reading this? I better dumb it down."

Of course not. A ridiculous idea. They use their tools the way they are 
designed to be used, and outsiders have to learn the language and the 
jargon to make sense of it. This is not a problem that needs solving.

It's one thing to simplify code that you are explicitly using as a 
teaching aid. That's a good thing, I approve of that. But it's a 
completely different thing to dumb down production code because you think 
some non-programmer might have to read it.



> 2. You should avoid constructs which can /reasonably/ be avoided to
>   /increase/ legibility.  Writing if x for if len(x) > 0 when you know
>   that x is of some sort of collection type with len defined does
>   nothing to help legibility.

Of course it does. 

It means you don't have to care about implementation details of what 
emptiness means for a list. It means you don't force the reader to read, 
parse and understand three extraneous terms. It means you don't force the 
reader to wonder why you bothered to use a long-winded test when a short 
test would do, or be concerned that maybe > 0 is a typo and you actually 
meant > 10.


[...]
> Simpler, yes, but it surely depends on more detailed knowledge.  One has
> to remember how the boolean conversion works, for each possible data
> type. This requires looking up the rules for each data type.

No. You have that exactly backwards. The point of "if x" is that you 
DON'T have to care about how the boolean conversion works, because the 
object itself encapsulates that behaviour. This is basic object-oriented 
principles.

When you call len(x) you don't care about the details of how to calculate 
the length of x. The object itself knows so that you don't have to. The 
same applies to truth testing.

I have a data type that is an array of lists. When you call "if len(x) > 
0" on it, it will blow up in your face, because len(x) returns a list of 
lengths like [12, 0, 2, 5]. But if you say "if x", it will do the right 
thing. You don't need to care how to truth-test my data type, because it 
does it for you. By ignoring my type's interface, and insisting on doing 
the truth-test by hand, you shoot yourself in the foot.



> E.g. Anyone who has used list/set comprehension in Z, haskell, set
> theory, or whereever will understand python list comprehension
> immediately.

Yes. And anyone who hasn't, probably won't. But they will learn.



-- 
Steven