On Tue, Apr 03, 2001 at 10:06:16AM -0700, Russell E. Owen wrote:
| 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).
I'd like to see a 'boolean' type added, with 2 (constant) instances,
'true' and 'false' in __builtins__. Putting them in __builtins__
wouldn't break even the code that initialized them (for example, try
None = "foo" ).
If I get around to it I might write a PEP. I would design 'true' and
'false' to compare against objects in the current fashion. For
example,
if "" == false :
print '"" is false'
would execute the print statement. The real usefulness is as an
argument or return value to/from a function. IMO the following is
clearer than the current alternatives in self-documenting the purpose
of it :
setVisible( true )
or
def is_condition( ) :
return true
In these cases it is clear that the return value is supposed to
indicate boolean usage, rather than possibly appearing to be
arithmetic.
| 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
If you want to have a (cache) flag somewhere, you would first set it
to "don't know", aka "not initialized yet". Then in the first
usage you could do the computation and set the flag to true or false.
Afterwards you simply need to check the flag and not perform the
computation again.
-D
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