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
parent
5a7a50435a
commit
c3075a1135
74
pep-0238.txt
74
pep-0238.txt
|
|
@ -251,27 +251,32 @@ API Changes
|
|||
|
||||
Command Line Option
|
||||
|
||||
The -D command line option takes a string argument that can take
|
||||
three values: "old", "warn", or "new". The default is "old" in
|
||||
Python 2.2 but will change to "warn" in later 2.x versions. The
|
||||
"old" value means the classic division operator acts as described.
|
||||
The "warn" value means the classic division operator issues a
|
||||
warning (a DeprecationWarning using the standard warning
|
||||
framework) when applied to ints or longs. The "new" value changes
|
||||
the default globally so that the / operator is always interpreted
|
||||
as true 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.
|
||||
The -Q command line option takes a string argument that can take
|
||||
four values: "old", "warn", "warnall", or "new". The default is
|
||||
"old" in Python 2.2 but will change to "warn" in later 2.x
|
||||
versions. The "old" value means the classic division operator
|
||||
acts as described. The "warn" value means the classic division
|
||||
operator issues a warning (a DeprecationWarning using the standard
|
||||
warning framework) when applied to ints or longs. The "warnall"
|
||||
value also issues warnings for classic division when applied to
|
||||
floats or complex; this is for use by the fixdiv.py conversion
|
||||
script mentioned below. The "new" value changes the default
|
||||
globally so that the / operator is always interpreted as true
|
||||
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
|
||||
always interpret / as true division.
|
||||
|
||||
(Other names have been proposed, like -Dclassic, -Dclassic-warn,
|
||||
-Dtrue, or -Dold_division etc.; these seem more 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
|
||||
(This option was originally proposed as -D, but that turned out to
|
||||
be an existing option for Jython, hence the Q -- mnemonic for
|
||||
Quotient. Other names have been proposed, like -Qclassic,
|
||||
-Qclassic-warn, -Qtrue, or -Qold_division etc.; these seem more
|
||||
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__.)
|
||||
|
||||
|
||||
|
|
@ -328,7 +333,7 @@ Semantics of True Division
|
|||
The Future Division Statement
|
||||
|
||||
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 (until Python 3.0 comes along, where they are always
|
||||
translated to true division).
|
||||
|
|
@ -359,8 +364,8 @@ Open Issues
|
|||
- 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
|
||||
party library package that requires -Qnew with another one that
|
||||
requires -Qold. 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.
|
||||
|
|
@ -370,7 +375,9 @@ Open Issues
|
|||
longs is much larger than that of Python floats. This problem
|
||||
will disappear if and when rational numbers are supported. In
|
||||
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__(),
|
||||
__floordiv__() and __truediv__() seems painful; and what to do
|
||||
|
|
@ -426,20 +433,19 @@ FAQ
|
|||
execfile(), eval() and exec?
|
||||
|
||||
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?
|
||||
|
||||
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.
|
||||
A. This is dealt with properly; see PEP 264[5].
|
||||
|
||||
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?
|
||||
|
||||
|
|
@ -452,9 +458,9 @@ FAQ
|
|||
|
||||
Implementation
|
||||
|
||||
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].
|
||||
Essentially everything mentioned here is implemented in CVS and
|
||||
will be released with Python 2.2a3; most of it was already
|
||||
released with Python 2.2a2.
|
||||
|
||||
|
||||
References
|
||||
|
|
@ -474,8 +480,8 @@ References
|
|||
[4] PEP 236, Back to the __future__, Peters,
|
||||
http://www.python.org/peps/pep-0236.html
|
||||
|
||||
[5] Patch 443474, from __future__ import division
|
||||
http://sourceforge.net/tracker/index.php?func=detail&aid=443474&group_id=5470&atid=305470
|
||||
[5] PEP 264, Future statements in simulated shells
|
||||
http://www.python.org/peps/pep-0236.html
|
||||
|
||||
|
||||
Copyright
|
||||
|
|
|
|||
Loading…
Reference in New Issue