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

False = 0
rather than
False == 0
and I lost the False statement.
Thus,
False 0

To get it back, I found that I could do
False = (1 == 2)
which seems to put False back to False, but this seems weird.
1 = 0
throws an error (can't assign to literal), why doesn't False = 0 throw the
same error? Also, why doesn't False = 0 make
1 == 2

0

Instead of False?

-d

[Peter Hansen]

drs wrote:

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

False = 0 rather than
False == 0
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.1 = 0
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 make1 == 2

0
Instead of False?

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

-Peter

[Steve Holden]

Peter Hansen wrote:

drs wrote:

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

> False = 0

rather than

> False == 0

and I lost the False statement.

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.

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

> 1 = 0

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.

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.

Also, why doesn't False = 0 make

> 1 == 2

0
Instead of False?

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.

None = 42 SyntaxError: assignment to None True = 33
True 33 __builtins__.True True __builtins__.True = 42
True 33 del True
True 42 Of course, even though you can change True's value, you can't make a
comparison return __builtins__.True:
None is None True (None is None) + 1 2

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
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC [phone] [phone]

[Steven Bethard]

drs wrote:

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

1 == 2

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