Silly questions about True and False

[drs]

I just upgraded my Python install, and for the first time have True and
False rather than 1 and 0. I was playing around at the command line to test
how they work (for instance, "if 9:" and "if True:" both lead to the
conditional being executed, but True == 9 -> False, that this would be true
was not obvious to me -- "True is True" is True, while "9 is True" is false
even though 9 evaluates to True.) Anyhow, in doing my tests, I accidentally
typed

rather than

and I lost the False statement.
Thus,
0

To get it back, I found that I could do

which seems to put False back to False, but this seems weird.

throws an error (can't assign to literal), why doesn't False = 0 throw the
same error? Also, why doesn't False = 0 make
0

Instead of False?

-d

 

[Peter Hansen]

I just upgraded my Python install, and for the first time have True and
False rather than 1 and 0. I was playing around at the command line to test
how they work (for instance, "if 9:" and "if True:" both lead to the
conditional being executed, but True == 9 -> False, that this would be true
was not obvious to me -- "True is True" is True, while "9 is True" is false
even though 9 evaluates to True.)

What do you mean by "9 evalutes to True"? That's not the
case. bool(9) does evaluate to True, and that's effectively
what "if 9:" is doing...

Anyhow, in doing my tests, I accidentally

typed


rather than


and I lost the False statement.

To get it back, you should do "del False". Remarkably,
this actually just removes the local name False that
you created which was "shadowing" the builtin name,
allowing the builtin name (which you didn't change)
to be seen again.

Note that this name you are creating is actually *local*
to the module you are in, which at the interactive
prompt is called __main__. Thus you are not changing
False from the point of view of any other module, or
of the Python internals. They are (for the most part)
still getting it from the builtin module.

which seems to put False back to False, but this seems weird.

throws an error (can't assign to literal), why doesn't False = 0 throw the
same error?

False is not a constant, it's merely a name. 1 and 0 are
constants. You can't change a constant, but you *can*
"rebind" a name (that is, attach it to something else).
That's all you're doing here.

Also, why doesn't False = 0 make
0
Instead of False?

Because such comparisons are all effectively doing a bool()
which continues to return the builtin False.

-Peter

 

[Steve Holden]

What do you mean by "9 evalutes to True"? That's not the
case. bool(9) does evaluate to True, and that's effectively
what "if 9:" is doing...

Anyhow, in doing my tests, I accidentally

I should point out a terminological inexactitude here: False is not a
statement, it's an identifier. As Peter pointed out, that identifier can
exist in several different namespaces, leading to your initial confusion.

To get it back, you should do "del False". Remarkably,
this actually just removes the local name False that
you created which was "shadowing" the builtin name,
allowing the builtin name (which you didn't change)
to be seen again.

Note that this name you are creating is actually *local*
to the module you are in, which at the interactive
prompt is called __main__. Thus you are not changing
False from the point of view of any other module, or
of the Python internals. They are (for the most part)
still getting it from the builtin module.




False is not a constant, it's merely a name. 1 and 0 are
constants. You can't change a constant, but you *can*
"rebind" a name (that is, attach it to something else).
That's all you're doing here.

Note, however, that the 2.4 documentation does actually list True and
False as constants (along with None) in section 2.5 of the Library
Reference manual.

Because such comparisons are all effectively doing a bool()
which continues to return the builtin False.

Sadly, the builtin False and True can actually be overwritten (unlike
None, which starting from 2.4 really *is* a constant):

$ python
Python 2.4 (#1, Dec 4 2004, 20:10:33)
[GCC 3.3.3 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.Of course, even though you can change True's value, you can't make a
comparison return __builtins__.True:

Here the comparison is returning the Python object to which
__builtins__.True initially refers.

when-i-tell-you-three-times-it-is-forty-true-ly y'rs - steve

 

[Steven Bethard]

I just upgraded my Python install, and for the first time have True and
False rather than 1 and 0. I was playing around at the command line to test
how they work (for instance, "if 9:" and "if True:" both lead to the
conditional being executed, but True == 9 -> False, that this would be true
was not obvious to me

Note that evaluating to True isn't the same as being equal to True.
Would you also expect that [] == None? Both evaluate to False in a
boolean context. Or an even better example, would you expect that
[1] == [2]? Both of these evaluate to True in a boolean context...

What you should expect is that:

py> bool([]) == bool(None) == False
True
py> bool([1]) == bool([2]) == True
True

"True is True" is True, while "9 is True" is false
even though 9 evaluates to True.)

Be careful here. 'is' tests object identity. So "9 is True" would only
evaluate to True if 9 is exactly the same object as True. 'is' won't
convert anything to a boolean; "x is y" basically translates to
"id(x) == id(y)".

why doesn't False = 0 throw the same error?

Backwards compatibility. A lot of modules pre-False and True have code
that looks like:

True, False = 1, 0

or

True, False = (1 == 1), (1 == 0)

If assignment to True or False became a syntax error (which it probably
should be), it would break all such code.

Also, why doesn't False = 0 make

0

Instead of False?

You've only rebound the name False in your module's namespace. 1 == 2
executes the int code for equality, which presumably returns one of
Py_False or Py_True, not your binding for the name False in your module.

Steve