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
--
http://mail.python.org/mailman/listinfo/python-list
