checking if a list is empty

[Steven D'Aprano]

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

> On Sat, 07 May 2011 21:57:13 -0700, Ethan Furman
>   <ethan at stoneleaf.us> wrote:
> :  If you're going to use a language, and use it well, you have to learn
> :  how that language works.
> 
> And if the world evolves around the compiler and you, that advice
> suffices.
> 
> However, programming is often as much about developing ideas in a large
> and complex community, where perfect universal mastery of one language
> is not an option, because half the community do not normally use that
> language or aren't really programmers at all.  The less you assume about
> the skill of the reader, the better it is.

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?

We routinely and uncontroversially use all of these techniques (well, 
sometimes metaclasses get a few raised eyebrows). Truth testing is MUCH 
simpler than any of those.

It is extremely patronizing to say that we should avoid truth-testing 
arbitrary objects because it is too complicated for other people. It's 
not hard, and they can learn.



-- 
Steven