PEP 285: Adding a bool type

[Chris Liechti]

Chris Barker <Chris.Barker at noaa.gov> wrote in 
news:3CAA03E4.A79BA593 at noaa.gov:
> WOW! fabulous post, Laura. As a result of mainly this post, I have
> changed my thinking somewhat.
> 
> Laura Creighton wrote:
> 
>> Python does not distinguish between True and
>> False -- Python makes the distinction between something and nothing.
>>
>> So I out-and-out tell people this.  {} is a dictionary-shaped nothing.
>> [] is a list-shaped nothing. 0 is an integer-shaped nothing.
>> 0.0 is a float shaped nothing.
>
> Thinking in terms of something vs. nothing is an excellent way to
> explain how Python treats these things, but I still have a problem with
> it. Who is to say that an empty list is nothing?

you can guide that in your classes with __nonzero__ (or __len__). if you 
don't care if the list is empty then make other tests like
>>> if var is None: ...

> or 0 for that matter. 0
> particularly: it is an integer, and a very useful one at that, I find it
> very inconvenient that 0 is always interpreted as nothing (see the
> string.find() example).

don't think of 'find' as a boolean operation. its result is an index, not a 
truth value. maybe it would be clearer if it returns None or raises an 
exception if nothing was found but its as it is now (the strstr C function 
return that values so it will come from there).

> In Python the only object I want consistently
> interpreted as nothing is None.

i find it especialy useful that other empty {list,dict,string} count as 
false. its a clear concept and it even saves you typing...
 
> That being said, the proposed "int-in-a-hat" (nice coinage, Laura), does
> not solve my problem at all. Everything that is currently interpreted as
> nothing will continue to be so interpreted, which is must be so as not
> to break probably every module over ten or so lines of code long.
> 
> The Python language is very much set in its ways: it relies on the
> concept of something vs. nothing, and it has pre-defined what nothing is
> for all the standard types in a very useful way. I'd be happier if that
> legacy didn't exist, but like many people posting, I feel this halfway
> measure is worse than what we have now.
> 
> Perhaps for Py3k, if we accept code breakage galor, a real Bool can be
> introduced, and we can get rid of de-facto definitions of particular
> values of an object being nothing. For now, let's keep it the way it is.

yes. but a real bool could be introduced as module for now (for the RPC and 
marshalling people that need one) i think its not needed otherwise becuse 
of the clean something/nothing logic wich only gets spoiled by a "backwards 
compatible" implementation.
we could watch how it evolves in the future. if its a clever thing it can 
become a builtin in py3k.

> -Chris

i can only agree with the rest :-) 

chris



-- 
Chris <cliechti at gmx.net>