Booleans (was: Conditional operator in Python?)

Russell E. Owen owen at astrono.junkwashington.emu
Tue Apr 3 13:06:16 EDT 2001


In article <mailman.986240224.15817.python-list at python.org>,
 Bruce Sass <bsass at freenet.edmonton.ab.ca> wrote:

>> But even if the Python development team suddenly became convinced that a
>> separate boolean type was the way to go, it'd be quite a challenge to
>> implement such a thing without breaking a vast amount of existing code.
>
>Why would adding something to the language break old code...
>just don't change the old behaviour.

Simply adding "true" and "false" constants or keywords or what-have-you 
would certainly clarify some code and would also certainly NOT break 
anything except code that already used these as names. I suspect most 
folks are not foolish enough to code with "true" or "false" (unless they 
are used to mean the obvious, in which case only the code that 
initializes them would break).

However, the broader issue is of a separate boolean type used for all 
logical operations. I personally think it's quite messy and confusing 
that any value has an associated logical value (e.g. 0 is false, any 
other integer is true, "" is false, any other string is true, etc.). But 
as I said in my previous posting, it's a widely used construct that 
doesn't seem to screw up languages too badly. And there's no way to 
change this in Python without breaking tons of code.

Regarding your boolean class, could you explain the value to adding 
"don't know" to it? I can imagine it has its uses, but it sounds like a 
different problem domain than standard conditional logic such as 
if/then/else. If you're aiming for fuzz logic then presumably you'd want 
more choices than simply true, false and don't know.

-- russell



More information about the Python-list mailing list