True/False

[Ian Bicking]

On Tue, 2003-04-22 at 13:42, Skip Montanaro wrote:
>     Ian> True, False = 1==1, 0==1
> 
> Why not
> 
>     try:
>         True
>     except NameError:
>         True, False = 1==1, 0==1
> 
> ?  Should work anywhere without complaints.

Yes, that's better than a version check.  I hate how much of this cruft
I'm getting at the top of my files, though... :(  I like Python for its
lack of boiler-plate code, but this feels like boiler-plate.

>     Ian> Is there any reason why reassigning True and False will be a
>     Ian> problem in the future?
> 
> The builtins may get "tightened up" in the future.  This particular idiom
> probably won't be affected, but you may not be able to (easily) shadow a
> builtin in another module's global namespace, e.g.:
> 
>     import a
>     a.True, a.False = 1==1, 0==1
> 
> might not be possible.  The idea here is to allow the byte compiler to know
> all the possible builtin shadowing that goes on in a module by examining
> just the module itself.  This, in turn, would allow access to builtins (and
> globals to some extent I think) to be optimized.

This was the sort of issue I was thinking about.  But another change is:

Python 2.3a2+ (#2, Mar 21 2003, 22:13:05) 
[GCC 3.2.3 20030316 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> None = 10
<stdin>:1: SyntaxWarning: assignment to None

Will this happen to True/False?  Probably not, because that would
*really* mess up backwards compatibility (since try:except: wouldn't
even work).

  Ian