Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv30375
Modified Files:
pep-0285.txt
Log Message:
Add a section with the most pressing issues for reviewers.
Index: pep-0285.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0285.txt,v
retrieving revision 1.11
retrieving revision 1.12
diff -C2 -d -r1.11 -r1.12
*** pep-0285.txt 30 Mar 2002 05:17:22 -0000 1.11
--- pep-0285.txt 30 Mar 2002 05:37:02 -0000 1.12
***************
*** 24,27 ****
--- 24,64 ----
+ 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
In directory usw-pr-cvs1:/tmp/cvs-serv30375
Modified Files:
pep-0285.txt
Log Message:
Add a section with the most pressing issues for reviewers.
Index: pep-0285.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0285.txt,v
retrieving revision 1.11
retrieving revision 1.12
diff -C2 -d -r1.11 -r1.12
*** pep-0285.txt 30 Mar 2002 05:17:22 -0000 1.11
--- pep-0285.txt 30 Mar 2002 05:37:02 -0000 1.12
***************
*** 24,27 ****
--- 24,64 ----
+ 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