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