[Python-checkins] CVS: python/nondist/peps pep-0238.txt,1.10,1.11
Guido van Rossum
gvanrossum@users.sourceforge.net
Fri, 27 Jul 2001 11:07:14 -0700
Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv5891
Modified Files:
pep-0238.txt
Log Message:
Worked in most of the comments on the newsgroup on the previous draft.
Even changed the title.
Index: pep-0238.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0238.txt,v
retrieving revision 1.10
retrieving revision 1.11
diff -C2 -d -r1.10 -r1.11
*** pep-0238.txt 2001/07/26 22:06:23 1.10
--- pep-0238.txt 2001/07/27 18:07:12 1.11
***************
*** 1,4 ****
PEP: 238
! Title: Non-integer Division
Version: $Revision$
Author: pep@zadka.site.co.il (Moshe Zadka), guido@python.org (Guido van Rossum)
--- 1,4 ----
PEP: 238
! Title: Changing the Division Operator
Version: $Revision$
Author: pep@zadka.site.co.il (Moshe Zadka), guido@python.org (Guido van Rossum)
***************
*** 7,11 ****
Created: 11-Mar-2001
Python-Version: 2.2
! Post-History: 16-Mar-2001, 26-Jul-2001
--- 7,11 ----
Created: 11-Mar-2001
Python-Version: 2.2
! Post-History: 16-Mar-2001, 26-Jul-2001, 27-Jul-2001
***************
*** 14,22 ****
The current division (/) operator has an ambiguous meaning for
numerical arguments: it returns the floor of the mathematical
! result if the arguments are ints or longs, but it returns a
! reasonable approximation of the result if the arguments are floats
! or complex. This makes expressions expecting float or complex
! results error-prone when integers are not expected but possible as
! inputs.
We propose to fix this by introducing different operators for
--- 14,22 ----
The current division (/) operator has an ambiguous meaning for
numerical arguments: it returns the floor of the mathematical
! result of division if the arguments are ints or longs, but it
! returns a reasonable approximation of the division result if the
! arguments are floats or complex. This makes expressions expecting
! float or complex results error-prone when integers are not
! expected but possible as inputs.
We propose to fix this by introducing different operators for
***************
*** 124,128 ****
Variations
! Esthetically, 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
--- 124,128 ----
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
***************
*** 149,153 ****
literals.) Replacing x/y with div(x, y) would require a much
more intelligent tool, since the extent of the expressions to
! the left and right of the / must be analized before the
placement of the "div(" and ")" part can be decided.
--- 149,153 ----
literals.) Replacing x/y with div(x, y) would require a much
more intelligent tool, since the extent of the expressions to
! the left and right of the / must be analyzed before the
placement of the "div(" and ")" part can be decided.
***************
*** 162,169 ****
- Let / keep its classic semantics; introduce // for true
! division. This doesn't solve the problem that the classic /
! operator makes it hard to write polymorphic numeric functions
! accept int and float arguments, and still requires the use of
! x*1.0/y whenever true divisions is required.
- Let int division return a special "portmanteau" type that
--- 162,168 ----
- Let / keep its classic semantics; introduce // for true
! division. This still leaves a broken operator in the language,
! and invites to use the broken behavior. It also shuts off the
! road to a unified numeric model a la PEP 228[0].
- Let int division return a special "portmanteau" type that
***************
*** 172,176 ****
operations, the int and the float value could be miles apart,
it's unclear which value should be used in comparisons, and of
! course many contexts (e.g. conversion to string) don't have a
clear integer or float context.
--- 171,175 ----
operations, the int and the float value could be miles apart,
it's unclear which value should be used in comparisons, and of
! course many contexts (like conversion to string) don't have a
clear integer or float context.
***************
*** 189,196 ****
version for which a specific piece of code was developed. This
requires future Python interpreters to be able to emulate
! *exactly* every previous version of Python, and moreover to do
! so for multiple versions in the same interpreter. This is way
! too much work. A much simpler solution is to keep multiple
! interpreters installed.
--- 188,195 ----
version for which a specific piece of code was developed. This
requires future Python interpreters to be able to emulate
! *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.
***************
*** 241,245 ****
--- 240,247 ----
exception. There is no fallback to the classic divide slot.
+ In Python 3.0, the classic division semantics will be removed; the
+ classic division APIs will become synonymous with true division.
+
Command Line Option
***************
*** 249,256 ****
"old" value means the classic division operator acts as described.
The "warn" value means the classic division operator issues a
! warning (a DeprecatinWarning 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
--- 251,258 ----
"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
***************
*** 260,263 ****
--- 262,272 ----
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__.)
+
Semantics of Floor Division
***************
*** 268,274 ****
a // b == floor(a/b)
! except that the type of a//b will be the type a and b will be
! coerced into. Specifically, if a and b are of the same type, a//b
! will be of that type too.
--- 277,302 ----
a // b == floor(a/b)
! except that the result type will be the common type into which a
! and b are coerced before the operation.
!
! Specifically, if a and b are of the same type, a//b will be of
! that type too. If the inputs are of different types, they are
! first coerced to a common type using the same rules used for all
! other arithmetic operators.
!
! In particular, if a and b are both ints or longs, the result has
! the same type and value as for classic division on these types
! (including the case of mixed input types; int//long and long//int
! will both return a long).
!
! For floating point inputs, the result is a float. For example:
!
! 3.5//2.0 == 1.0
!
! For complex numbers, // raises an exception, since float() of a
! complex number is not allowed.
!
! For user-defined classes and extension types, all semantics are up
! to the implementation of the class or type.
***************
*** 277,283 ****
True division for ints and longs will convert the arguments to
float and then apply a float division. That is, even 2/1 will
! return a float (2.0), not an int.
The Future Division Statement
--- 305,323 ----
True division for ints and longs will convert the arguments to
float and then apply a float division. That is, even 2/1 will
! return a float (2.0), not an int. For floats and complex, it will
! be the same as classic division.
+ Note that for long arguments, true division may lose information;
+ this is in the nature of true division (as long as rationals are
+ not in the language). Algorithms that consciously use longs
+ should consider using //.
+ If and when a rational type is added to Python (see PEP 239[2]),
+ true division for ints and longs should probably return a
+ rational. This avoids the problem with true division of longs
+ losing information. But until then, for consistency, float is the
+ only choice for true division.
+
+
The Future Division Statement
***************
*** 293,303 ****
See PEP 236[4] for the general rules for future statements.
Open Issues
! - It has been proposed to call // the quotient operator. I like
! this. I might rewrite the PEP to use this if enough people like
! it. (But isn't the assumption that this truncates towards
! zero?)
- It has been argued that a command line option to change the
--- 333,349 ----
See PEP 236[4] for the general rules for future statements.
+ (It has been proposed to use a longer phrase, like "true_division"
+ or "modern_division". These don't seem to add much information.)
+
Open Issues
! - It has been proposed to call // the quotient operator, and the /
! operator the ratio operator. I'm not sure about this -- for
! some people quotient is just a synonym for division, and ratio
! suggests rational numbers, which is wrong. I prefer the
! terminology to be slightly awkward if that avoids unambiguity.
! Also, for some folks "quotient" suggests truncation towards
! zero, not towards infinity as "floor division" says explicitly.
- It has been argued that a command line option to change the
***************
*** 313,316 ****
--- 359,374 ----
FAQ
+ Q. Why isn't true division called float division?
+
+ A. Because I want to keep the door open to *possibly* introducing
+ rationals and making 1/2 return a rational rather than a
+ float. See PEP 239[2].
+
+ Q. Why is there a need for __truediv__ and __itruediv__?
+
+ A. We don't want to make user-defined classes second-class
+ citizens. Certainly not with the type/class unification going
+ on.
+
Q. How do I write code that works under the classic rules as well
as under the new rules without using // or a future division
***************
*** 319,323 ****
A. Use x*1.0/y for true division, divmod(x, y)[0] for int
division. Especially the latter is best hidden inside a
! function. You may also write floor(x)/y for true division if
you are sure that you don't expect complex numbers. If you
know your integers are never negative, you can use int(x/y) --
--- 377,381 ----
A. Use x*1.0/y for true division, divmod(x, y)[0] for int
division. Especially the latter is best hidden inside a
! function. You may also write float(x)/y for true division if
you are sure that you don't expect complex numbers. If you
know your integers are never negative, you can use int(x/y) --
***************
*** 343,346 ****
--- 401,408 ----
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?