Question For Language Lawyers - WAS: Re: Combining colon statements on one line?

[Christopher T King]

On 19 Jul 2004, Tim Daneliuk wrote:

> OK, this is clever, but I have a question for the Language Lawyers
> here:
> 
>     It is really good style to depend upon boolean True and False
>     being 1 and 0?  It seems to me that, especially in an OO
>     language, True and False ought to be treated as abstract
>     boolean objects.

I remember reading something about this in a previous thread, and I think
it was decided that int(True) will always evaluate to 1, and int(False)
will similarly always evaluate to 0.  So it may not be good style, but it 
should be guaranteed behaviour for some time.  (Note: AFAICT, this isn't 
in the official language spec, though.)

>     In particular, assuming they are 1 and 0
>     (it seems to me) promotes something about the language
>     _implementation) into the application code which is a Bad
>     Thing.

Not necessarily -- you aren't really assuming they're 1 and 0 in Python 
((1 is True) == False), but rather that they evaluate to 1 and 0 in an 
integer context, which is something that can be (and it seems is) as well 
defined as the fact that float(1) evaluates to 1.0.

This does bring up the discrepancy that somelist[True] works, while 
somelist[1.0] doesn't.  Dunno what to say about that :P

>     I actually resort to this sort of stuff to keep
>     things as abstract as possible:
> 
>              F = 1 == 0
>              T = not F

I used to do the same thing in C for a while:

#define FALSE 0
#define TRUE !FALSE

Though this came about because I had previously used VB, where -1 is the
canonical true value, as opposed to the value of 1 used in C, and for some
odd reason I was relying on this implementation detail.  Moral: VB is 
hazardous to your health :)