[Python-checkins] CVS: python/nondist/peps pep-0238.txt,1.16,1.17
Guido van Rossum
gvanrossum@users.sourceforge.net
Mon, 03 Sep 2001 20:48:50 -0700
Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv8197
Modified Files:
pep-0238.txt
Log Message:
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.
Index: pep-0238.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0238.txt,v
retrieving revision 1.16
retrieving revision 1.17
diff -C2 -d -r1.16 -r1.17
*** pep-0238.txt 2001/08/07 15:30:11 1.16
--- pep-0238.txt 2001/09/04 03:48:48 1.17
***************
*** 252,276 ****
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.
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
__truediv__.)
--- 252,281 ----
Command Line Option
! 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.
! (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__.)
***************
*** 329,333 ****
If "from __future__ import division" is present in a module, or if
! -Dnew 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
--- 334,338 ----
If "from __future__ import division" is present in a module, or if
! -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
***************
*** 360,365 ****
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
to enable true division by default, and other educators might
need the same. These usually have enough control over the
--- 365,370 ----
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 -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
***************
*** 371,375 ****
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.
- For classes to have to support all three of __div__(),
--- 376,382 ----
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. 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__(),
***************
*** 427,444 ****
A. They inherit the choice from the invoking module. PEP 236[4]
! lists this as a partially resolved problem.
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.
Q. Will there be conversion tools or aids?
! A. Certainly, but these are outside the scope of the PEP.
Q. Why is my question not answered here?
--- 434,450 ----
A. They inherit the choice from the invoking module. PEP 236[4]
! now lists this as a resolved problem, referring to PEP 264[5].
Q. What about code compiled by the codeop module?
! A. This is dealt with properly; see PEP 264[5].
Q. Will there be conversion tools or aids?
! 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?
***************
*** 453,459 ****
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].
--- 459,465 ----
Implementation
! 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.
***************
*** 475,480 ****
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
--- 481,486 ----
http://www.python.org/peps/pep-0236.html
! [5] PEP 264, Future statements in simulated shells
! http://www.python.org/peps/pep-0236.html