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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4