Discuss x \ y as rejected variation; reorganize the section on

variations slightly to allow more easily adding new variations.

Add more discussion of why I don't like version directives.

pep-0238.txt

@@ -124,13 +124,9 @@ Motivation
 Variations
 
     Aesthetically, x//y doesn't please everyone, and hence several
-    variations have been proposed: x div y, or div(x, y), sometimes in
-    combination with x mod y or mod(x, y) as an alternative spelling
-    for x%y.
+    variations have been proposed.  They are addressed here:
 
-    We consider these solutions inferior, on the following grounds.
-
-    - Using x div y would introduce a new keyword.  Since div is a
+    - x div y.  This would introduce a new keyword.  Since div is a
       popular identifier, this would break a fair amount of existing
       code, unless the new keyword was only recognized under a future
       division statement.  Since it is expected that the majority of
@@ -140,7 +136,7 @@ Variations
       adding new keywords unless absolutely necessary argues against
       this.
 
-    - Using div(x, y) makes the conversion of old code much harder.
+    - div(x, y).  This makes the conversion of old code much harder.
       Replacing x/y with x//y or x div y can be done with a simple
       query replace; in most cases the programmer can easily verify
       that a particular module only works with integers so all
@@ -151,6 +147,11 @@ Variations
       the left and right of the / must be analyzed before the
       placement of the "div(" and ")" part can be decided.
 
+    - x \ y.  The backslash is already a token, meaning line
+      continuation, and in general it suggests an "escape" to Unix
+      eyes.  In addition (this due to terry Reedy) this would make
+      things like eval("x\y") harder to get right.
+
 
 Alternatives
 
@@ -190,7 +191,12 @@ Alternatives
       *exactly* several previous versions of Python, and moreover to
       do so for multiple versions within the same interpreter.  This
       is way too much work.  A much simpler solution is to keep
-      multiple interpreters installed.
+      multiple interpreters installed.  Another argument against this
+      is that the version directive is almost always overspecified:
+      most code written for Python X.Y, works for Python X.(Y-1) and
+      X.(Y+1) as well, so specifying X.Y as a version is more
+      constraining than it needs to be.  At the same time, there's no
+      way to know at which future or past version the code will break.
 
 
 API Changes