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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4