Only in Python 2, since that is a backward-compatibility feature. (“False” and “True” used to be variables containing 0 and 1 before Python had true booleans, many ages ago.) Python 3 makes “True” and “False” be constant values, like “1” or “2”, like they should be.
Yes. There are codes written with backwards compatibility to versions of Python pre-2.3, which did not have True/False. They typically looked like this:
Couldn't that be kept compatible by allowing tautological assignments to True/False (True = (1==1), that sort of thing) but throwing an error on all other assignments?
Also, I don't see how that wouldn't be compatible with forbidding assignments to True/False. It'd never execute the except block.
Yes, that specific case is possible with some sort of AST rewriting. But it's only one of several ways to introduce a True into the module or local namespace. Another might be:
from _compat import True, False, next, enumerate
This is allowed under Python 2, but not under Python 3. As you suggest, it could be made possible to allow an import like this so long as the actual imported value is indeed the True or False singleton. But it's a lot of work with little gain.
While on the other hand, even in Python 2 it was a SyntaxError to say "None = None" or to import None. Extending that check to include True and False is much easier, and consistent with existing use.
What bothers me here is that when the interpreter says "False", it clearly means the opposite of (the new) False. So by reassigning True and False, I've actually caused inconsistent behavior in python, not just really-confusingly-named behavior. Suddenly False sometimes means one thing and sometimes means something else.
There's no inconsistency, the "False" printed in your console is just the repr of the object, you can give that repr to your own object if you have nothing better to do with your life:
A repr is just a representation in development context, nothing more and nothing less, there is no requirement that it be sensible or of any use, though that's certainly recommended (contrary to __str__/__unicode__ which should be silly):
>>> B()
A gray parrot
The only "inconsistency" you've created is that False in the console's local namespace does not match __builtins__.False or the interpreter's internal False object. You can still access the former by the way:
the interpreter still does not care though, you've just broken any Python code relying on the builtin (you can actually alter the "true" False object via ctypes)