165 lines
4.8 KiB
Plaintext
165 lines
4.8 KiB
Plaintext
PEP: 237
|
||
Title: Unifying Long Integers and Integers
|
||
Version: $Revision$
|
||
Author: pep@zadka.site.co.il (Moshe Zadka), guido@python.org (Guido van Rossum)
|
||
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.
|
||
|
||
Note from second author: this PEP requires more thought about
|
||
implementation details. I've started to make a list of semantic
|
||
differences but I doubt it's complete.
|
||
|
||
|
||
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.
|
||
|
||
|
||
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).
|
||
|
||
|
||
Implementation
|
||
|
||
There are two alternative implementations to choose from.
|
||
|
||
1. 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.
|
||
|
||
2. The existing short and long int types remain, but the short int
|
||
returns a long int instead of raising OverflowError.
|
||
|
||
|
||
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:
|