Movatterモバイル変換
[0]ホーム
[Python-Dev] PEP 285 (Adding a bool type) extending it further
Martin v. Loewismartin@v.loewis.de
04 Oct 2002 07:56:28 +0200
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 allresponses you get to earlier messages. You are also supposed to doloads 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 beendiscussed 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 saidthat 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 abetter rationale.It is unclear to me why you have to override those operators in thefirst place. I would assume that every problem that involvesboolean-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 Pythonlanguage, and people rely on it. Applications would break if you tookit away. In software development, the computational meaning of aprogram is important, not the algebraic one - even in functionallanguages, 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 thelanguage, and confuse newcomers.Regards,Martin
[8]ページ先頭