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: