[Python-checkins] CVS: python/nondist/peps pep-0238.txt,1.10,1.11

2001年7月27日 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?