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