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

[Martin v. Loewis]

Marcelo Matus <mmatus@dinha.acms.arizona.edu> writes:

> I am sorry if this is not the right forum for this topic, in that case
> please tell me.

The forum is right, but you really have to read carefully all
responses you get to earlier messages. You are also supposed to do
loads of research before speaking up.

> 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.

That is unfortunate, indeed. However, this specific issue has been
discussed many times before, so you could have known.

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

We understand why you said this. Please also understand why Guido said
that PEP 285 is closed and done.

> 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:

If you really insist on having such a feature, you'll have to give a
better rationale.

It is unclear to me why you have to override those operators in the
first place. I would assume that every problem that involves
boolean-ness of some object can be solved by implementing __nonzero__.

> 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.

Can you please break you lines equally?

> 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.

It so happens that the semantics is considered part of the Python
language, and people rely on it. Applications would break if you took
it away. In software development, the computational meaning of a
program is important, not the algebraic one - even in functional
languages, people could never settle on the issue of strictness.


> Therefore, the addition of the pure boolean operators "&&,||,!"
> seems to be Salomonic solution.

I find that solution very ugly. It would add more line noise to the
language, and confuse newcomers.

Regards,
Martin