128 lines
3.3 KiB
Plaintext
128 lines
3.3 KiB
Plaintext
PEP: 237
|
||
Title: Unifying Long Integers and Integers
|
||
Version: $Revision$
|
||
Author: pep@zadka.site.co.il (Moshe Zadka)
|
||
Status: Draft
|
||
Type: Standards Track
|
||
Created: 11-Mar-2001
|
||
Python-Version: 2.2
|
||
Post-History: 16-Mar-2001
|
||
|
||
|
||
Abstract
|
||
|
||
Python has both integers (machine word size integral) types, and
|
||
long integers (unbounded integral) types. When integers
|
||
operations overflow the machine registers, they raise an error.
|
||
This PEP proposes to do away with the distinction, and unify the
|
||
types from the perspective of both the Python interpreter and the
|
||
C API.
|
||
|
||
|
||
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.
|
||
|
||
|
||
Literals
|
||
|
||
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.
|
||
|
||
|
||
Builtin Functions
|
||
|
||
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:
|
||
|
||
long=int
|
||
|
||
at the top of the module, or:
|
||
|
||
import __builtin__
|
||
__builtin__.long=int
|
||
|
||
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.
|
||
|
||
|
||
Implementation
|
||
|
||
The PyInt type's slot for a C long will be turned into a
|
||
|
||
union {
|
||
long i;
|
||
struct {
|
||
unsigned long length;
|
||
digit digits[1];
|
||
} bignum;
|
||
};
|
||
|
||
Only the n-1 lower bits of the long have any meaning; the top bit
|
||
is always set. This distinguishes the union. All PyInt functions
|
||
will check this bit before deciding which types of operations to
|
||
use.
|
||
|
||
|
||
Jython Issues
|
||
|
||
Jython will have a PyInt interface which is implemented by both
|
||
from PyFixNum and PyBigNum.
|
||
|
||
|
||
Open Issues
|
||
|
||
What to do about sys.maxint?
|
||
|
||
What to do about PyInt_AS_LONG failures?
|
||
|
||
What do do about %u, %o, %x formatting operators?
|
||
|
||
How to warn about << not cutting integers?
|
||
|
||
Should the overflow warning be on a portable maximum size?
|
||
|
||
Will unification of types and classes help with a more straightforward
|
||
implementations?
|
||
|
||
Define an C API that can be used to find out what the representation of an
|
||
int is.
|
||
|
||
|
||
Copyright
|
||
|
||
This document has been placed in the public domain.
|
||
|
||
|
||
|
||
Local Variables:
|
||
mode: indented-text
|
||
indent-tabs-mode: nil
|
||
End:
|