Chetan pandyacus.xspam at xspam.sbcglobal.net
Sun Oct 29 07:08:32 CET 2006

```Gabriel Genellina <gagsl-py at yahoo.com.ar> writes:

> At Friday 27/10/2006 23:13, Steve Holden wrote:
>
>>J. Clifford Dyer wrote:
>> > the one thing that Ms. Creighton points out that I can't get past is
>> > that Python, even with its bool type, *still* evaluates somethingness
>> > and nothingness, and True and False are just numbers with hats on.
>> >
>> >  >>> True + 3
>> > 4
>> >  >>> bool(True-1)
>> > False
>> >  >>> bool(True-2)
>> > True
>> >  >>> (10 > 5) + (10 < 5)
>> > 1
>>Seems pretty clear to me that the situations you discuss above involve
>>numeric coercions of a Boolean value.
>
> A "true" Boolean value should not be coerced into any other thing. True+1 is as
> meaningless as "A"+1, or even "1"+1. The fact is, bool is just an integer in
> disguise.
> I always regretted that Python just went mid-way moving onto a true Boolean
> type; I'd prefer it to stay as it was before bool was introduced.
>
>> > Python is not evaluating the truth of the matter, but, as Ms. Creighton
>> > would say, the "somethingness" of that which 10 > 5 evaluates to.  (1
>> > aka True)
>> >
>>   >>> type(10>5)
>><type 'bool'>
>>   >>>
>
>>>> bool.__mro__
> (<type 'bool'>, <type 'int'>, <type 'object'>)
>
>>It does seem that there is a specific type associated with the result of
>>a comparison, even though you would really like to to be "a number with
>>a hat on".
>
> It *is* an integer with a hat on.
>
>>>> isinstance(True,int)
> True
This has focussed on the relational operators, which seem to produce a number
with a hat on. However, logical operations do not do so.
True and "This string" produces "This string", for example.

This is hardly surprising, though.
The way they are defined, booleans seem to be the syntactic sugar that some
people like. Many of the projects that I have been associated with had such
a define because the language (C) does not provide it. On the other hand,
there are many who do just fine without them.

For expressions used in control flow, if the expression somehow produces a 0
(False included) or None, the behavior is as if the expression is false.
Confusion may arise because the way that answer is produced may not be
immediately obvious. For constructs such as "if obj:" the answer depends on
which methods the object has defined and what the state of the object is at the
time, but this has nothing to do with whether the answer that was produced was
strictly a boolean or not.

Chetan

>
>
> --
> Gabriel Genellina
> Softlab SRL
>
> __________________________________________________
> Correo Yahoo!
> Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrí tu cuenta
> ya! - http://correo.yahoo.com.ar

```