Lots of updates, more rationale, explicit transition plan.
This commit is contained in:
Guido van Rossum
parent
560f0fe45a
commit
bff4d98e03
221
pep-0237.txt
221
pep-0237.txt
|
|
@ -27,81 +27,45 @@ Rationale
|
|||
|
||||
Having the machine word size exposed to the language hinders
|
||||
portability. For examples Python source files and .pyc's are not
|
||||
portable because of this. Many programs find a need to deal with
|
||||
larger numbers after the fact, and changing the algorithms later
|
||||
is not only bothersome, but hinders performance in the normal
|
||||
case.
|
||||
portable between 32-bit and 64-bit machines because of this. Many
|
||||
programs find a need to deal with larger numbers after the fact,
|
||||
and changing the algorithms later is not only bothersome, but
|
||||
hinders performance in the normal case.
|
||||
|
||||
There is also the general desire to hide unnecessary details from
|
||||
the Python user when they are irrelevant for most applications.
|
||||
(Another example is memory allocation, which explicit in C but
|
||||
automatic in Python, giving us the convenience of unlimited sizes
|
||||
on strings, lists, etc.)
|
||||
|
||||
It will give new Python programmers (whether they are new to
|
||||
programming in general or not) one less thing to learn before they
|
||||
can start using the language.
|
||||
|
||||
|
||||
Literals
|
||||
Transition
|
||||
|
||||
A trailing 'L' at the end of an integer literal will stop having
|
||||
any meaning, and will be eventually phased out. This will be done
|
||||
using warnings when encountering such literals. The warning will
|
||||
be off by default in Python 2.2, on for 12 months, which will
|
||||
probably mean Python 2.3 and 2.4, and then will no longer be
|
||||
supported.
|
||||
There are three phases of the transition:
|
||||
|
||||
1. Ints and longs are treated the same, no warnings are issued for
|
||||
code that uses longs. Warnings for the use of longs (either
|
||||
long literals, ending in 'L' or 'l', or use of the long()
|
||||
function) may be enabled through a command line option.
|
||||
|
||||
Builtin Functions
|
||||
2. Longs are treated the same as ints but their use triggers a
|
||||
warning (which may be turned off or turned into an error using
|
||||
the -W command line option).
|
||||
|
||||
The function long() will call the function int(), issuing a
|
||||
warning. The warning will be off in 2.2, and on for two revisions
|
||||
before removing the function. A FAQ will be added to explain that
|
||||
a solutions for old modules are:
|
||||
3. Long literals and (if we choose implementation plan 1 below)
|
||||
the long() built-in are no longer legal.
|
||||
|
||||
long=int
|
||||
We propose the following timeline:
|
||||
|
||||
at the top of the module, or:
|
||||
1. Python 2.2.
|
||||
|
||||
import __builtin__
|
||||
__builtin__.long=int
|
||||
2. The rest of the Python 2.x line.
|
||||
|
||||
In site.py.
|
||||
|
||||
|
||||
C API
|
||||
|
||||
All PyLong_As* will call PyInt_As*. If PyInt_As* does not exist,
|
||||
it will be added. Similarly for PyLong_From*. A similar path of
|
||||
warnings as for the Python builtins will be followed.
|
||||
|
||||
|
||||
Overflows
|
||||
|
||||
When an arithmetic operation on two numbers whose internal
|
||||
representation is as machine-level integers returns something
|
||||
whose internal representation is a bignum, a warning which is
|
||||
turned off by default will be issued. This is only a debugging
|
||||
aid, and has no guaranteed semantics.
|
||||
|
||||
|
||||
Semantic Differences
|
||||
|
||||
The following operations have (usually subtly) different semantics
|
||||
for short and for long integers, and one will have to change
|
||||
somehow. This is intended to be an exhaustive list; if you know
|
||||
of anything else that might change, please write the author.
|
||||
|
||||
- Currently, all arithmetic operators on short ints except <<
|
||||
raise OverflowError if the result cannot be represented as a
|
||||
short int. This will change (of course).
|
||||
|
||||
- Currently x<<n can lose bits for short ints. No more.
|
||||
|
||||
- Currently, hex and oct literals for for short ints may specify
|
||||
negative values; for example 0xffffffff == -1 on a 32-bint
|
||||
machine. No more; this will equal 2**32-1.
|
||||
|
||||
- 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.
|
||||
|
||||
- Currently, type(x) may reveal the difference between short and
|
||||
long ints. This may or may not change (see Implementation
|
||||
below).
|
||||
3. Python 3.0 (at least two years in the future).
|
||||
|
||||
|
||||
Implementation
|
||||
|
|
@ -124,7 +88,98 @@ Implementation
|
|||
use.
|
||||
|
||||
2. The existing short and long int types remain, but the short int
|
||||
returns a long int instead of raising OverflowError.
|
||||
returns a long int instead of raising OverflowError when a
|
||||
result cannot be represented as a short int. A new type,
|
||||
integer, may be introduced that is an abstract base type of
|
||||
which both the int and long implementation types are
|
||||
subclassed. This is useful so that programs can check
|
||||
integer-ness with a single test:
|
||||
|
||||
if isinstance(i, integer): ...
|
||||
|
||||
|
||||
Literals
|
||||
|
||||
A trailing 'L' at the end of an integer literal will stop having
|
||||
any meaning, and will be eventually phased out.
|
||||
|
||||
|
||||
Built-in Functions
|
||||
|
||||
The function long() will call the function int(). If
|
||||
implementation plan 1 is chosen, it will eventually be phased out;
|
||||
with implementation plan 2, it remains in the language to
|
||||
represent the long implementation type -- but the int() function
|
||||
is still recommended, since it will automatically return a long
|
||||
when needed.
|
||||
|
||||
|
||||
C API
|
||||
|
||||
If implementation plan 1 is chosen, all PyLong_As* will call
|
||||
PyInt_As*. If PyInt_As* does not exist, it will be added.
|
||||
Similarly for PyLong_From*. A similar path of warnings as for the
|
||||
Python built-ins will be followed.
|
||||
|
||||
If implementation plan 2 is chosen, the C API remains unchanged.
|
||||
|
||||
(The PyArg_Parse*() APIs already accept long ints, as long as they
|
||||
are within the range representable by C ints or longs. This will
|
||||
remain unchanged.)
|
||||
|
||||
|
||||
Overflows
|
||||
|
||||
When an arithmetic operation on two numbers whose internal
|
||||
representation is as machine-level integers returns something
|
||||
whose internal representation is a bignum, a warning which is
|
||||
turned off by default will be issued. This is only a debugging
|
||||
aid, and has no guaranteed semantics.
|
||||
|
||||
A command line option may be used to enable these warnings (the
|
||||
regular warning framework supports warnings that are off by
|
||||
default, but this is be too slow -- it makes a call to an
|
||||
complex piece of Python code).
|
||||
|
||||
This warning is not part of the transition plan; it will always be
|
||||
off by default, and the feature will probably disappear in Python
|
||||
3.0.
|
||||
|
||||
|
||||
Semantic Changes
|
||||
|
||||
The following operations have (usually subtly) different semantics
|
||||
for short and for long integers, and one will have to change
|
||||
somehow. This is intended to be an exhaustive list; if you know
|
||||
of anything else that might change, please write the author.
|
||||
|
||||
- Currently, all arithmetic operators on short ints except <<
|
||||
raise OverflowError if the result cannot be represented as a
|
||||
short int. This will change (of course).
|
||||
|
||||
- Currently x<<n can lose bits for short ints. No more.
|
||||
|
||||
- Currently, hex and oct literals for for short ints may specify
|
||||
negative values; for example 0xffffffff == -1 on a 32-bint
|
||||
machine. No more; this will equal 0xffffffffL which is 2**32-1.
|
||||
|
||||
- Currently, the '%u', '%x' and '%o' string formatting operators
|
||||
and the hex() and oct() built-in functions behave differently
|
||||
for negative numbers: negative short ints are formatted as
|
||||
unsigned C long, while negative long ints are formatted with a
|
||||
minus sign. The long int semantics will rule (but without the
|
||||
trailing 'L' that currently distinguishes the output of hex()
|
||||
and oct() for long ints).
|
||||
|
||||
- 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 (it allows an optimization). This
|
||||
is only relevant if implementation plan 2 is chosen.
|
||||
|
||||
- Currently, type(x) may reveal the difference between short and
|
||||
long ints. This will change if implementation plan 1 is chosen.
|
||||
|
||||
|
||||
Jython Issues
|
||||
|
|
@ -132,24 +187,40 @@ Jython Issues
|
|||
Jython will have a PyInt interface which is implemented by both
|
||||
from PyFixNum and PyBigNum.
|
||||
|
||||
(Question for the Jython developers -- do you foresee any other
|
||||
problems?)
|
||||
|
||||
|
||||
Open Issues
|
||||
|
||||
What to do about sys.maxint?
|
||||
We expect that these issues will be resolved over time, as more
|
||||
feedback is received or we gather more experience with the initial
|
||||
implementation.
|
||||
|
||||
What to do about PyInt_AS_LONG failures?
|
||||
- Which implementation plan to choose? Moshe is for plan 1, Guido
|
||||
is for plan 2. Plan 2 seems less work. Plan 1 probably breaks
|
||||
more at the C API level, e.g. PyInt_AS_LONG below.
|
||||
|
||||
What do do about %u, %o, %x formatting operators?
|
||||
- What to do about sys.maxint? (If implementation plan 1 is
|
||||
chosen, it should probably be phased out; for plan 2, it is
|
||||
still meaningful.)
|
||||
|
||||
How to warn about << not cutting integers?
|
||||
- What to do about PyInt_AS_LONG failures? (Only relevant with
|
||||
implementation plan 1.)
|
||||
|
||||
Should the overflow warning be on a portable maximum size?
|
||||
- What do do about %u, %o, %x formatting operators?
|
||||
|
||||
Will unification of types and classes help with a more straightforward
|
||||
implementations?
|
||||
- Should we warn about << not cutting integers?
|
||||
|
||||
Define an C API that can be used to find out what the representation of an
|
||||
int is.
|
||||
- Should the overflow warning be on a portable maximum size?
|
||||
|
||||
- Will unification of types and classes help with a more
|
||||
straightforward implementation? (Yes, it allows a common base
|
||||
class.)
|
||||
|
||||
- Define an C API that can be used to find out what the
|
||||
representation of an int is (only relevant for implementation
|
||||
plan 1).
|
||||
|
||||
|
||||
Copyright
|
||||
|
|
|
|||
Loading…
Reference in New Issue