From 9cec34b016b3afeee96e2ae02a4169797fd25072 Mon Sep 17 00:00:00 2001 From: Guido van Rossum Date: Sat, 30 Mar 2002 05:37:02 +0000 Subject: [PATCH] Add a section with the most pressing issues for reviewers. --- pep-0285.txt | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/pep-0285.txt b/pep-0285.txt index 00957874a..4039d92ae 100644 --- a/pep-0285.txt +++ b/pep-0285.txt @@ -23,6 +23,43 @@ Abstract isinstance(). +Review + + Dear reviewers: + + I'm particularly interested in hearing your opinion about the + following three issues: + + 1) Should this PEP be accepted at all. + + 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".) + + 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. + + 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. + + 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. + + Rationale Most languages eventually grow a Boolean type; even C99 (the new