Add a section with the most pressing issues for reviewers.

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