checking if a list is empty

[Hans Georg Schaathun]

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.  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.

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.  Many of the socalled advanced
  constructs you mention are used to increase legibility one way or
  another.  Others will simply allow functionality which would otherwise
  be impossible.

  I don't object to using if x in a case where x may or may not have
  len() defined.

:  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.

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.

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

:  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.

Again you miss the point.  It is not /too/ complicated.
It is /unnecessarily/ complicated.  You don't noticeably
gain anything by using if x instead of if len(x) > 0, if
you know that the latter is defined.  

If everyone who ever needs to see your program is a python
programmer, then your approach works as well as mine.  

-- 
:-- Hans Georg