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

Rename the -D option to -Q, to avoid a Jython option name conflict. 

Document the 4th value of this option (warnall).

Also update some other items that are now resolved or close to being
resolved.
This commit is contained in:
Guido van Rossum 2001-09-04 03:48:48 +00:00
parent 5a7a50435a
commit c3075a1135
1 changed files with 40 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

74
pep-0238.txt
View File

@ -251,27 +251,32 @@ API Changes
Command Line Option Command Line Option
The -D command line option takes a string argument that can take The -Q command line option takes a string argument that can take
three values: "old", "warn", or "new". The default is "old" in four values: "old", "warn", "warnall", or "new". The default is
Python 2.2 but will change to "warn" in later 2.x versions. The "old" in Python 2.2 but will change to "warn" in later 2.x
"old" value means the classic division operator acts as described. versions. The "old" value means the classic division operator
The "warn" value means the classic division operator issues a acts as described. The "warn" value means the classic division
warning (a DeprecationWarning using the standard warning operator issues a warning (a DeprecationWarning using the standard
framework) when applied to ints or longs. The "new" value changes warning framework) when applied to ints or longs. The "warnall"
the default globally so that the / operator is always interpreted value also issues warnings for classic division when applied to
as true division. The "new" option is only intended for use in floats or complex; this is for use by the fixdiv.py conversion
certain educational environments, where true division is required, script mentioned below. The "new" value changes the default
but asking the students to include the future division statement globally so that the / operator is always interpreted as true
in all their code would be a problem. division. The "new" option is only intended for use in certain
educational environments, where true division is required, but
asking the students to include the future division statement in
all their code would be a problem.
This option will not be supported in Python 3.0; Python 3.0 will This option will not be supported in Python 3.0; Python 3.0 will
always interpret / as true division. always interpret / as true division.
(Other names have been proposed, like -Dclassic, -Dclassic-warn, (This option was originally proposed as -D, but that turned out to
-Dtrue, or -Dold_division etc.; these seem more verbose to me be an existing option for Jython, hence the Q -- mnemonic for
without much advantage. After all the term classic division is Quotient. Other names have been proposed, like -Qclassic,
not used in the language at all (only in the PEP), and the term -Qclassic-warn, -Qtrue, or -Qold_division etc.; these seem more
true division is rarely used in the language -- only in verbose to me without much advantage. After all the term classic
division is not used in the language at all (only in the PEP), and
the term true division is rarely used in the language -- only in
__truediv__.) __truediv__.)
@ -328,7 +333,7 @@ Semantics of True Division
The Future Division Statement The Future Division Statement
If "from __future__ import division" is present in a module, or if If "from __future__ import division" is present in a module, or if
-Dnew is used, the / and /= operators are translated to true -Qnew is used, the / and /= operators are translated to true
division opcodes; otherwise they are translated to classic division opcodes; otherwise they are translated to classic
division (until Python 3.0 comes along, where they are always division (until Python 3.0 comes along, where they are always
translated to true division). translated to true division).
@ -359,8 +364,8 @@ Open Issues
- It has been argued that a command line option to change the - It has been argued that a command line option to change the
default is evil. It can certainly be dangerous in the wrong default is evil. It can certainly be dangerous in the wrong
hands: for example, it would be impossible to combine a 3rd hands: for example, it would be impossible to combine a 3rd
party library package that requires -Dnew with another one that party library package that requires -Qnew with another one that
requires -Dold. But I believe that the VPython folks need a way requires -Qold. But I believe that the VPython folks need a way
to enable true division by default, and other educators might to enable true division by default, and other educators might
need the same. These usually have enough control over the need the same. These usually have enough control over the
library packages available in their environment. library packages available in their environment.
@ -370,7 +375,9 @@ Open Issues
longs is much larger than that of Python floats. This problem longs is much larger than that of Python floats. This problem
will disappear if and when rational numbers are supported. In will disappear if and when rational numbers are supported. In
the interim, maybe the long-to-float conversion could be made to the interim, maybe the long-to-float conversion could be made to
raise OverflowError if the long is out of range. raise OverflowError if the long is out of range. Tim Peters
will make sure that whenever an in-range float is returned,
decent precision is guaranteed.
- For classes to have to support all three of __div__(), - For classes to have to support all three of __div__(),
__floordiv__() and __truediv__() seems painful; and what to do __floordiv__() and __truediv__() seems painful; and what to do
@ -426,20 +433,19 @@ FAQ
execfile(), eval() and exec? execfile(), eval() and exec?
A. They inherit the choice from the invoking module. PEP 236[4] A. They inherit the choice from the invoking module. PEP 236[4]
lists this as a partially resolved problem. now lists this as a resolved problem, referring to PEP 264[5].
Q. What about code compiled by the codeop module? Q. What about code compiled by the codeop module?
A. Alas, this will always use the default semantics (set by the -D A. This is dealt with properly; see PEP 264[5].
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. Will there be conversion tools or aids? Q. Will there be conversion tools or aids?
A. Certainly, but these are outside the scope of the PEP. A. Certainly. While these are outside the scope of the PEP, I
should point out two simple tools that will be released with
Python 2.2a3: Tools/scripts/finddiv.py finds division operators
(slightly smarter than "grep /") and Tools/scripts/fixdiv.py
can produce patches based on run-time analysis.
Q. Why is my question not answered here? Q. Why is my question not answered here?
@ -452,9 +458,9 @@ FAQ
Implementation Implementation
A very early implementation (not yet following the above spec, but Essentially everything mentioned here is implemented in CVS and
supporting // and the future division statement) is available from will be released with Python 2.2a3; most of it was already
the SourceForge patch manager[5]. released with Python 2.2a2.
References References
@ -474,8 +480,8 @@ References
[4] PEP 236, Back to the __future__, Peters, [4] PEP 236, Back to the __future__, Peters,
http://www.python.org/peps/pep-0236.html http://www.python.org/peps/pep-0236.html
[5] Patch 443474, from __future__ import division [5] PEP 264, Future statements in simulated shells
http://sourceforge.net/tracker/index.php?func=detail&aid=443474&group_id=5470&atid=305470 http://www.python.org/peps/pep-0236.html
Copyright Copyright