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.
This commit is contained in:
Guido van Rossum
parent
a1e2aca28a
commit
c2ae605f20
86
pep-0237.txt
86
pep-0237.txt
|
|
@ -116,19 +116,24 @@ Incompatibilities
|
|||
'%d'. It will eventually be removed.
|
||||
|
||||
- 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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
remain (at least until Python 3.0).
|
||||
|
||||
- Short ints with small values (typically between -1 and 99
|
||||
inclusive) are "interned" -- whenever a result has such a value,
|
||||
|
|
@ -146,22 +151,28 @@ Literals
|
|||
A trailing 'L' at the end of an integer literal will stop having
|
||||
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.)
|
||||
|
||||
|
||||
Built-in Functions
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
|
||||
C API
|
||||
|
||||
The C API remains unchanged; C code will still need to be aware of
|
||||
the difference between short and long ints.
|
||||
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
|
||||
are within the range representable by C ints or longs, so that
|
||||
|
|
@ -171,7 +182,7 @@ C API
|
|||
|
||||
Transition
|
||||
|
||||
There are two major phases to the transition:
|
||||
There are three major phases to the transition:
|
||||
|
||||
A. Short int operations that currently raise OverflowError return
|
||||
a long int value instead. This is the only change in this
|
||||
|
|
@ -186,39 +197,30 @@ Transition
|
|||
the warnings module) will allow a warning or an error to be
|
||||
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.
|
||||
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 starting with Python 2.3. Envisioned
|
||||
stages of phase B:
|
||||
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
|
||||
numeric outcome in stage B1, in particular hex() and oct(),
|
||||
'%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.
|
||||
shifts losing bits.
|
||||
|
||||
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.
|
||||
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:
|
||||
|
||||
|
|
@ -226,11 +228,8 @@ Transition
|
|||
|
||||
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).
|
||||
Phase C will be implemented in Python 3.0 (at least two years
|
||||
after Python 2.4 is released).
|
||||
|
||||
|
||||
OverflowWarning
|
||||
|
|
@ -322,9 +321,10 @@ Resolved Issues
|
|||
|
||||
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.
|
||||
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).
|
||||
|
||||
|
||||
Copyright
|
||||
|
|
|
|||
Loading…
Reference in New Issue