[Python-checkins] python/nondist/peps pep-0237.txt,1.16,1.17
gvanrossum at users.sourceforge.net
gvanrossum at users.sourceforge.net
Mon Dec 1 20:22:52 EST 2003
Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1:/tmp/cvs-serv13682
Modified Files:
pep-0237.txt
Log Message:
Record recent changes of heart (see python-dev):
- No warnings for operations that changed semantics between 2.3 and 2.4.
- Trailing 'L' remains in repr() of long ints until Python 3.0.
Index: pep-0237.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0237.txt,v
retrieving revision 1.16
retrieving revision 1.17
diff -C2 -d -r1.16 -r1.17
*** pep-0237.txt 7 Nov 2002 15:41:19 -0000 1.16
--- pep-0237.txt 2 Dec 2003 01:22:50 -0000 1.17
***************
*** 117,133 ****
- Currently, repr() of a long int returns a string ending in 'L'
! while repr() of a short int doesn't. The 'L' will be dropped.
- Currently, an operation with long operands will never return a
short int. This *may* change, since it allows some
! optimization.
- The expression type(x).__name__ depends on whether x is a short
or a long int. Since implementation alternative 2 is chosen,
! this difference will remain.
- Long and short ints are handled different by the marshal module,
and by the pickle and cPickle modules. This difference will
! remain.
- Short ints with small values (typically between -1 and 99
--- 117,138 ----
- Currently, repr() of a long int returns a string ending in 'L'
! while repr() of a short int doesn't. The 'L' will be dropped;
! but not before Python 3.0.
- Currently, an operation with long operands will never return a
short int. This *may* change, since it allows some
! optimization. (No changes have been made in this area yet, and
! none are planned.)
- The expression type(x).__name__ depends on whether x is a short
or a long int. Since implementation alternative 2 is chosen,
! this difference will remain. (In Python 3.0, we *may* be able
! to deploy a trick to hide the difference, because it *is*
! annoying to reveal the difference to user code, and more so as
! the difference between the two types is less visible.)
- Long and short ints are handled different by the marshal module,
and by the pickle and cPickle modules. This difference will
! remain (at least until Python 3.0).
- Short ints with small values (typically between -1 and 99
***************
*** 147,150 ****
--- 152,158 ----
any meaning, and will be eventually become illegal. The compiler
will choose the appropriate type solely based on the value.
+ (Until Python 3.0, it will force the literal to be a long; but
+ literals without a trailing 'L' may also be long, if they are not
+ representable as short ints.)
***************
*** 152,160 ****
The function int() will return a short or a long int depending on
! the argument value. The function long() will call the function
! int(). The built-in name 'long' will remain in the language to
! represent the long implementation type, but using the int()
! function is still recommended, since it will automatically return
! a long when needed.
--- 160,170 ----
The function int() will return a short or a long int depending on
! the argument value. In Python 3.0, the function long() will call
! the function int(); before then, it will continue to force the
! result to be a long int, but otherwise work the same way as int().
! The built-in name 'long' will remain in the language to represent
! the long implementation type (unless it is completely eradicated
! in Python 3.0), but using the int() function is still recommended,
! since it will automatically return a long when needed.
***************
*** 162,166 ****
The C API remains unchanged; C code will still need to be aware of
! the difference between short and long ints.
The PyArg_Parse*() APIs already accept long ints, as long as they
--- 172,177 ----
The C API remains unchanged; C code will still need to be aware of
! the difference between short and long ints. (The Python 3.0 C API
! will probably be completely incompatible.)
The PyArg_Parse*() APIs already accept long ints, as long as they
***************
*** 172,176 ****
Transition
! There are two major phases to the transition:
A. Short int operations that currently raise OverflowError return
--- 183,187 ----
Transition
! There are three major phases to the transition:
A. Short int operations that currently raise OverflowError return
***************
*** 187,203 ****
issued at this point, but this is off by default.
! B. The remaining semantic differences are addressed. In most
! cases the long int semantics will prevail; however, the
! trailing 'L' from long int representations will be dropped.
! Eventually, support for integer literals with a trailing 'L'
! will be removed. Since this will introduce backwards
! incompatibilities which will break some old code, this phase
! may require a future statement and/or warnings, and a
! prolonged transition phase.
Phase A will be implemented in Python 2.2.
! Phase B will be implemented starting with Python 2.3. Envisioned
! stages of phase B:
B0. Warnings are enabled about operations that will change their
--- 198,215 ----
issued at this point, but this is off by default.
! B. The remaining semantic differences are addressed. In all cases
! the long int semantics will prevail. Since this will introduce
! backwards incompatibilities which will break some old code,
! this phase may require a future statement and/or warnings, and
! a prolonged transition phase. The trailing 'L' will continue
! to be used for longs as input and by repr().
!
! C. The trailing 'L' is dropped from repr(), and made illegal on
! input. (If possible, the 'long' type completely disappears.)
Phase A will be implemented in Python 2.2.
! Phase B will be implemented gradually in Python 2.3 and Python
! 2.4. Envisioned stages of phase B:
B0. Warnings are enabled about operations that will change their
***************
*** 205,223 ****
'%u', '%x', '%X' and '%o', hex and oct literals in the
(inclusive) range [sys.maxint+1, sys.maxint*2+1], and left
! shifts losing bits; but not repr() of a long.
!
! B1. The remaining semantic differences are addressed. Operations
! that give different results than before will issue a warning
! that is on by default. A warning for the use of long literals
! (with a trailing 'L') may be enabled through a command line
! option, but it is off by default.
!
! B2. (This stage is deleted.)
!
! B3. The warnings about operations that give different results than
! before are turned off by default.
! B4. Long literals are no longer legal. All warnings related to
! this issue are gone.
We propose the following timeline:
--- 217,225 ----
'%u', '%x', '%X' and '%o', hex and oct literals in the
(inclusive) range [sys.maxint+1, sys.maxint*2+1], and left
! shifts losing bits.
! B1. The new semantic for these operations are implemented.
! Operations that give different results than before will *not*
! issue a warning.
We propose the following timeline:
***************
*** 227,235 ****
B1. Python 2.4.
! B2. (Not applicable.)
!
! B3. The rest of the Python 2.x line.
!
! B4. Python 3.0 (at least two years in the future).
--- 229,234 ----
B1. Python 2.4.
! Phase C will be implemented in Python 3.0 (at least two years
! after Python 2.4 is released).
***************
*** 323,329 ****
Implementation
! A complete implementation of phase A is present in the current CVS
! tree and will be released with Python 2.2a3. (It didn't make it
! into 2.2a2.) Still missing are documentation and a test suite.
--- 322,329 ----
Implementation
! The implementation work for the Python 2.x line is completed;
! phase A was released with Python 2.2, phase B0 with Python 2.3,
! and phase B1 will be released with Python 2.4 (and is already in
! CVS).
More information about the Python-checkins
mailing list