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 3 2256
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
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 +1 703 861 4237 +1 800 494 3119
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 This discussion thread is closed Replies have been disabled for this discussion. Similar topics
reply
views
Thread by Ray Tayek |
last post: by
|
reply
views
Thread by Henry |
last post: by
|
1 post
views
Thread by TBK |
last post: by
|
2 posts
views
Thread by Mark P |
last post: by
|
5 posts
views
Thread by rhino |
last post: by
|
23 posts
views
Thread by sophia.agnes |
last post: by
|
8 posts
views
Thread by Geoff Cox |
last post: by
|
9 posts
views
Thread by Euvin |
last post: by
| | | | | | | | | | | |