iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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.
This commit is contained in:
Guido van Rossum 2001-08-07 02:52:37 +00:00
parent 91099711dd
commit e70ec5b0fa
1 changed files with 14 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
pep-0238.txt
View File

@ -124,13 +124,9 @@ Motivation
Variations Variations
Aesthetically, x//y doesn't please everyone, and hence several Aesthetically, x//y doesn't please everyone, and hence several
variations have been proposed: x div y, or div(x, y), sometimes in variations have been proposed. They are addressed here:
combination with x mod y or mod(x, y) as an alternative spelling
for x%y.
We consider these solutions inferior, on the following grounds. - x div y. This would introduce a new keyword. Since div is a
- Using x div y would introduce a new keyword. Since div is a
popular identifier, this would break a fair amount of existing popular identifier, this would break a fair amount of existing
code, unless the new keyword was only recognized under a future code, unless the new keyword was only recognized under a future
division statement. Since it is expected that the majority of division statement. Since it is expected that the majority of
@ -140,7 +136,7 @@ Variations
adding new keywords unless absolutely necessary argues against adding new keywords unless absolutely necessary argues against
this. 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 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 query replace; in most cases the programmer can easily verify
that a particular module only works with integers so all 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 the left and right of the / must be analyzed before the
placement of the "div(" and ")" part can be decided. 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 Alternatives
@ -190,7 +191,12 @@ Alternatives
*exactly* several previous versions of Python, and moreover to *exactly* several previous versions of Python, and moreover to
do so for multiple versions within the same interpreter. This do so for multiple versions within the same interpreter. This
is way too much work. A much simpler solution is to keep 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 API Changes