checking if a list is empty

[harrismh777]

Ian Kelly wrote:
> "bool(list)" describes whether the list contains something.  "Not"
> being a logical operator, it stands to reason that "not list" should
> mean the same thing as "not bool(list)".

Ian, James,

    Agreed, and thank you.  This *is* the explanation I was trying to 
prompt D'Aprano for, rather than getting his 'not cat' analogy.

    James, the argument is not for argument sake. The argument is to 
better facilitate understanding for others who are also trying to make 
sense of new ideas, some of whom are lurking.  :)   This argument 
actually goes back to a previous discussion D'Aprano and I (and others) 
were having pertaining to whether software is mathematics.

    It is easy to see how that negating a binary value ( on or off ) 
works with 'not'...   because there are only two possible states.

not on, means off....   not off, means on.

Same with '1' and '0'  where we have only two states, or True and False 
where we have only two states... &etc.   But when we have a list, what 
two states are we really discussing?  Aren't we really talking about set 
theory?  A list is an ordered collection of 'stuff' comprising a set. 
Negating the set   'not set'  is saying   'not bool(set)'  /

The two states are either 1) the elements of the set, or 2) not the 
elements of the set--- the empty set, or that 'stuff' outside the set.

The answer to the 'not list' question has to do with the conceived 
semantics of Python ordered collections, which are based more in 
mathematics proper (set theory) than in logic--- the 'not' operator. It 
is better to explain to students where the syntax is based (as Ian did) 
than to state uniformly, "This is just the way Python does it!".

As a side point, the answer, "This is the way Python does it!"... would 
be o.k. if-and-only-if Python were a standardized language, which it 
isn't.   Python's greatest strength is also its greatest weakness... 
that it is constantly evolving through the PEP process. James, one of 
the reasons we argue about language features is for that very purpose 
invited by PEP (and other feedback mechanisms, including this list). The 
community decides over time how Python does things (along with the final 
stamp, I suppose, of Guido the BDFL). So, we must needs be arguing, but 
its not for pedantic squabbling sake....   :-)


kind regards,
m harris