PEP 285: Adding a bool type

Robin Becker robin at jessikat.fsnet.co.uk
Sat Mar 30 03:35:33 EST 2002


In article <mailman.1017466974.6751.python-list at python.org>, Guido van
Rossum <guido at python.org> writes
......
This pretty much seems unwanted to me. Done purely for political
correctness. Whenever new keywords are discussed the Gods are against
them. Now we have to accept new constants true, false + a new type.
Silly like all those programmers who have constants like one and zero or
ten in code.

If we get bools can sets be far behind, and what about quaternions and
abelian groups?

>Review
>
>    Dear reviewers:
>
>    I'm particularly interested in hearing your opinion about the
>    following three issues:
>
>    1) Should this PEP be accepted at all.
no. If needed implement a library module for those who want to bog down
their code. This will not improve the python interpreter one bit and has
already consumed vast quantities of hot air ie has taken time and effort
away from more important issues.
>
>    2) Should str(True) return "True" or "1": "1" might reduce
>       backwards compatibility problems, but looks strange to me.
>       (repr(True) would always return "True".)
>
if yes to 1,  str(true) == "1", str(false) == "0"
>    3) Should the constants be called 'True' and 'False'
>       (corresponding to None) or 'true' and 'false' (as in C++, Java
>       and C99).
>
>    Most other details of the proposal are pretty much forced by the
>    backwards compatibility requirement; e.g. True == 1 and
>    True+1 == 2 must hold, else reams of existing code would break.
>
true, false
>    Minor additional issues:
>
>    4) Should we strive to eliminate non-Boolean operations on bools
>       in the future, through suitable warnings, so that e.g. True+1
>       would eventually (e.g. in Python 3000 be illegal).  Personally,
>       I think we shouldn't; 28+isleap(y) seems totally reasonable to
>       me.
>
no true==1, false==0 is what's required.
>    5) Should operator.truth(x) return an int or a bool.  Tim Peters
>       believes it should return an int because it's been documented
>       as such.  I think it should return a bool; most other standard
>       predicates (e.g. issubtype()) have also been documented as
>       returning 0 or 1, and it's obvious that we want to change those
>       to return a bool.
int
-- 
Robin Becker



More information about the Python-list mailing list