checking if a list is empty

[Steven D'Aprano]

On Sat, 07 May 2011 22:50:55 -0500, harrismh777 wrote:

> Steven D'Aprano wrote:

>>> >  and implies in any case that li does not exist
>> It does nothing of the sort. If li doesn't exist, you get a NameError.
> 
>       That was the point.   'not' implies something that is not logical;

I'm afraid that makes no sense to me. How does "does not exist" imply 
something not logical? In what way is "this is not my house" implying 
something not logical?


> which is irony extreme since 'not' is typically considered a logical
> operator.

Because "not" is typically used as a logical operator.

In English, it negates a word or statement:

"the cat is not on the mat" --> "the cat is on the mat" is false.

As an operator, "not" negates a true value to a false value. In 
mathematical Boolean algebra, there only is one true value and one false 
value, conventionally called True/False or 1/0. In non-Boolean algebras, 
you can define other values. In three-value logic, the negation of True/
False/Maybe is usually False/True/Maybe. In fuzzy logic, the logic values 
are the uncountable infinity (that's a technical term, not hyperbole) of 
real numbers between 0 and 1.

Python uses a boolean algebra where there are many ways of spelling the 
true and false values. The "not" operator returns the canonical bool 
values:

not <any true value> returns False
not <any false value> returns True

Take note of the distinction between lower-case true/false, which are 
adjectives, and True/False, which are objects of class bool.

This is not unique to Python. I understand the practice of allowing any 
value to be used in boolean expressions comes from Lisp in 1958, which 
makes it practically antediluvian.

Lisp uses the empty list and the special atom NIL as false values, any 
other s-expression is true. Scheme is different: it defines a special 
false atom, and empty lists are considered true. In Ruby, only the false 
object and the null object are considered false. In Forth, any non-zero 
word is true. In Javascript, the empty string, null, undefined, NaN, +0, 
-0, and false are all considered false.



> What does it mean to say  not <list name>?  Well, apparently
> it means the list is 'empty'... but why should it mean that? 

Because that is the definition chosen by the language designers. It is 
based on the fact that distinguishing between "something" and "nothing" 
is useful, common, fundamental, and applies to nearly all data types.


> Why not
> have it mean the list has been reversed in place?  Why not have it mean
> that the list isn't homogeneous?  Why not have it mean that its not
> mutable?  I could think of more... 

Because those tests are not fundamental tests that deserve to be elevated 
to a language design feature, any more than we need a built-in function 
to add 27 and three quarters to the argument.


> Why should 'not' mean 'empty'?

Because the test of "is this nothing, or something?" is a common, useful 
test:

0 (nothing) vs 1, 2, 3, ... (something)
empty list versus non-empty list
empty dict versus non-empty dict
empty set versus non-empty set
empty string versus non-empty string
no search results returned versus some search results returned
no network connection available versus some network connection available
no food in the cupboard versus food in the cupboard

This is a fundamental distinction which is very useful in practice. 


>>> >  or worse is some kind of boolean.
>> Only if you're still thinking in some language that isn't Python.
> 
>     Which most of us are... hate to remind you...   

Time to stop then. This is Python, not whatever language you're thinking 
in. Don't force language A into the conceptual pigeonholes of language B. 
To be effective in a programming language, you need to understand how 
that language works, and not see everything filtered through the 
conceptual framework of another language.

Bringing the viewpoints of other languages is a good thing. Python 
borrows concepts from many languages (sometimes what it borrows is the 
idea of "that's not how to do it"). And many idioms do cross language 
boundaries. But in general, it pays to think, and code, in the 
appropriate style for whatever language you are writing in. And 
certainly, you should not argue that a language feature is invalid or 
wrong merely because that's not how another language does it.

Or, to put it another way:

http://dirtsimple.org/2004/12/python-is-not-java.html
http://dirtsimple.org/2004/12/java-is-not-python-either.html



> Python is the new kid on the block, 

Nonsense. Python is 20 years old (1991), which makes it older than:

Java, PHP, Ruby (1995)
Javascript (1996)
C# (2000)
Visual Basic .Net (2001)

to say nothing of dozens of other languages.


> and most of us are coming at this from multiple
> filters in comp sci experience.  Its just the truth.

There's nothing wrong with having experience in many languages. That's a 
good thing.




-- 
Steven