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.
Comments
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:
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.