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

2001年7月26日 15:06:25 -0700

Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv3574
Modified Files:
	pep-0238.txt 
Log Message:
Some more alternatives and questions; added an "open issues" section.
Index: pep-0238.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0238.txt,v
retrieving revision 1.9
retrieving revision 1.10
diff -C2 -d -r1.9 -r1.10
*** pep-0238.txt	2001年07月26日 19:29:39	1.9
--- pep-0238.txt	2001年07月26日 22:06:23	1.10
***************
*** 7,11 ****
 Created: 11-Mar-2001
 Python-Version: 2.2
! Post-History: 16-Mar-2001

--- 7,11 ----
 Created: 11-Mar-2001
 Python-Version: 2.2
! Post-History: 16-Mar-2001, 26-Jul-2001

***************
*** 167,170 ****
--- 167,178 ----
 x*1.0/y whenever true divisions is required.

+ - Let int division return a special "portmanteau" type that
+ behaves as an integer in integer context, but like a float in a
+ float context. The problem with this is that after a few
+ 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.
+ 
 - Use a directive to use specific division semantics in a module,
 rather than a future statement. This retains classic division
***************
*** 286,289 ****
--- 294,314 ----

+ 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
+ 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
+ library packages available in their environment.
+ 
+ 
 FAQ

***************
*** 304,317 ****
 towards negative infinity, while int() rounds towards zero.

! Q. Why is my question not listed here?

! A. Because we weren't of it. If you've discussed it on c.l.py,
! please mail the second author.

 Implementation

! A very early implementation (not yet following the above spec
! is available from the SourceForge patch manager[5].

--- 329,361 ----
 towards negative infinity, while int() rounds towards zero.

! Q. How do I specify the division semantics for input(), compile(),
! execfile(), eval() and exec?

! 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. Why is my question not answered here?
! 
! A. Because we weren't aware of it. If it's been discussed on
! c.l.py and you believe the answer is of general interest,
! please notify the second author. (We don't have the time or
! inclination to answer every question sent in private email,
! hence the requirement that it be discussed on c.l.py first.)

 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].