From e70ec5b0fab693573d5a25c90474784539bbcc6f Mon Sep 17 00:00:00 2001 From: Guido van Rossum Date: Tue, 7 Aug 2001 02:52:37 +0000 Subject: [PATCH] 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 | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/pep-0238.txt b/pep-0238.txt index 72cc33676..44e58ccc1 100644 --- a/pep-0238.txt +++ b/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