Some more alternatives and questions; added an "open issues" section.

pep-0238.txt

@@ -6,7 +6,7 @@ Status: Draft
 Type: Standards Track
 Created: 11-Mar-2001
 Python-Version: 2.2
-Post-History: 16-Mar-2001
+Post-History: 16-Mar-2001, 26-Jul-2001
 
 
 Abstract
@@ -166,6 +166,14 @@ Alternatives
       accept int and float arguments, and still requires the use of
       x*1.0/y whenever true divisions is required.
 
+    - Let int division return a special "portmanteau" type that
+      behaves as an integer in integer context, but like a float in a
+      float context.  The problem with this is that after a few
+      operations, the int and the float value could be miles apart,
+      it's unclear which value should be used in comparisons, and of
+      course many contexts (e.g. conversion to string) don't have a
+      clear integer or float context.
+
     - Use a directive to use specific division semantics in a module,
       rather than a future statement.  This retains classic division
       as a permanent wart in the language, requiring future
@@ -285,6 +293,23 @@ The Future Division Statement
     See PEP 236[4] for the general rules for future statements.
 
 
+Open Issues
+
+    - It has been proposed to call // the quotient operator.  I like
+      this.  I might rewrite the PEP to use this if enough people like
+      it.  (But isn't the assumption that this truncates towards
+      zero?)
+
+    - It has been argued that a command line option to change the
+      default is evil.  It can certainly be dangerous in the wrong
+      hands: for example, it would be impossible to combine a 3rd
+      party library package that requires -Dnew with another one that
+      requires -Dold.  But I believe that the VPython folks need a way
+      to enable true division by default, and other educators might
+      need the same.  These usually have enough control over the
+      library packages available in their environment.
+
+
 FAQ
 
     Q. How do I write code that works under the classic rules as well
@@ -303,16 +328,35 @@ FAQ
        negative ints, classic division (and floor division) round
        towards negative infinity, while int() rounds towards zero.
 
-    Q. Why is my question not listed here?
+    Q. How do I specify the division semantics for input(), compile(),
+       execfile(), eval() and exec?
 
-    A. Because we weren't of it.  If you've discussed it on c.l.py,
-       please mail the second author.
+    A. They inherit the choice from the invoking module.  PEP 236[4]
+       lists this as a partially resolved problem.
+
+    Q. What about code compiled by the codeop module?
+
+    A. Alas, this will always use the default semantics (set by the -D
+       command line option).  This is a general problem with the
+       future statement; PEP 236[4] lists it as an unresolved
+       problem.  You could have your own clone of codeop.py that
+       includes a future division statement, but that's not a general
+       solution.
+
+    Q. Why is my question not answered here?
+
+    A. Because we weren't aware of it.  If it's been discussed on
+       c.l.py and you believe the answer is of general interest,
+       please notify the second author.  (We don't have the time or
+       inclination to answer every question sent in private email,
+       hence the requirement that it be discussed on c.l.py first.)
 
 
 Implementation
 
-    A very early implementation (not yet following the above spec
-     is available from the SourceForge patch manager[5].
+    A very early implementation (not yet following the above spec, but
+    supporting // and the future division statement) is available from
+    the SourceForge patch manager[5].
 
 
 References