True/False

[Ian Bicking]

On Wed, 2003-04-23 at 00:29, Martin v. Löwis wrote:
> Erik Max Francis <max at alcyone.com> writes:
> 
> > but at this point it's looking awfully ugly.
> 
> That's why it will take a long time until Python warns about
> assignments to True/False. Essentially, when Python 2.3 is considered
> an old Python version (i.e. at Python 4.0), the warning may be
> enabled. If the warning hasn't been seen for some time (say, at Python
> 6.2), it becomes an error. 
> 
> So the typical process is that people will have to actively break
> backwards compatibility at some time by removing the assignment.
> There is still a point in writing
> 
> try:
>   True
> except NameError:
>   True, False = 1, 0
> 
> as this gives you the "proper" boolean objects in 2.3+.

Note that the idiom I've been using (and which I've seen elsewhere) is:

True, False = 1==1, 0==1

Which retains proper boolean objects.  Or maybe one might use:

True, False = not 0, not 1

I'm a fan of True and False as being distinct from integers, which is
why I use the names, and I certainly wouldn't want to clobber their
proper values.

> b) import True, False from a module that doesn't get installed
>    in Python 2.3+
> try:
>    from boolcompat import *
> except ImportError:
>    pass

You could also make a boolcompat like:

# boolcompat.py
try:
    True
except NameError:
    from _boolcompat import *

# _boolcompat.py
True, False = 1==1, 0==1


This protects against SyntaxWarning and doesn't require try:except: in
the calling module.  But, despite these advantages, I won't be using 
it :)

  Ian