[Python-Dev] PEP 285 (Adding a bool type) extending it further

[Marcelo Matus]

Guido van Rossum wrote:

>>Given my silly problems trying to write a class which overwrite
>>logical operations like 'and', 'or' and 'not', which is not possible
>>by now [...]  I would like to propose to extend the PEP 285 to add
>>boolean operations that can be overloaded as the rest of the
>>operations in python.
>>    
>>
>
>Sorry, PEP 285 is already accepted and implemented, and your proposal
>has nothing to do with a Boolean type.  I've tried to explained before
>why this can't be done.
>
>--Guido van Rossum (home page: http://www.python.org/~guido/)
>  
>
I am sorry if this is not the right forum for this topic, in that case 
please tell me.

Also, I am sorry because it seems there were some crossover of mails, 
and I've got
your answer after sending the request to extend the PEP 285. And when
I ask to extend the PEP 285 I am not that literal, the proposed changes
could be included later, maybe in another PEP.

I said this proposal is an extension of the PEP 285 because it is 
related to the
boolean support in python.

And as you could see in one of the other emails, I understood the problem
and the sugestions were well taken, so now what I am proposing is not to 
change or
modify the 'and' or 'or' operators, because of the expected shortcut 
property.

Instead what I am proposing now is the addition of the pure boolean 
operators
&&, || and !, that like their bitwise versions &,| and ~, they don't 
require nor warranty
any shortcut property, but they could be overloaded, and in the default 
case,
they call the traditional 'and', 'or' and 'not' versions.

Why I insist on this instead of only use the bitwise versions &,|, ~ and 
just "leave it at that"?,
let me show you why :


By now my classes are overloading the the &,|, ~ versions as replacement
of the logical versions, but this have to be done with extreme carefull. 
Just
a simple example show the problem:

Assume I have a  set of classes which overload the bitwise operation
as a replacement of the logical ones, and then I write the following 
function

def cond(a, b, c):
    return  (~a | b) & ~c      # for meaning (not a or b) and  not c


well, this function will work with my classes, but if I want to mix my 
classes
with the real boolean and integer types, then what will be the result?.
If you, for example, set a=1; b=1 and c=1 then

print ~a | b & ~c                      ==> -2      (which means true)

print (not a or b) and  not c    ==> 0       (which means false)


therefore, replacing the 'and', 'or' and 'not' by '&,|,^'  is clearly 
dangerous
and at the end wrong because you can warranty the proper behaviour.

Now, maybe this proposal "has nothing to do with a Boolean type" as you
said, but once python starts to support the Boolean type, one could 
expect that this
means more than just an uniform way to name and/or  manage the True and 
False
values. Real booelan operators and, as for almost all the other types in 
python, the
real capability to overload them, is also important.

Finally, as you can  see, the shortcut property in the 'and', 'or' and 
 'not' operators
is really important in the "computational  sense", but to implement a real
boolean algebra, like in the bitwise operations "&,|,^", that is secondary.

Therefore, the addition of the pure boolean operators "&&,||,!" seems to
be  Salomonic solution. They do not interfere with the "computationaly 
oriented"
'and', 'or' and 'not', but they allow you to implement new (and correct)
boolean relations between you own types.


Marcelo