From 467a7e9c13dc99aed5e7cc9d11e625e1a328cf66 Mon Sep 17 00:00:00 2001
From: Barry Warsaw <barry@python.org>
Date: Fri, 16 Mar 2001 04:11:01 +0000
Subject: [PATCH] PEP 237, Unifying Long Integers and Integers, Moshe Zadka

[checking in for Moshe, after editorial, spell check, and formatting
passes by Barry]
---
 pep-0237.txt | 121 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 121 insertions(+)
 create mode 100644 pep-0237.txt

diff --git a/pep-0237.txt b/pep-0237.txt
new file mode 100644
index 000000000..436973bff
--- /dev/null
+++ b/pep-0237.txt
@@ -0,0 +1,121 @@
+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:
+
+
+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 bignum {
+                unsigned long length;
+                digit digits[1];
+            }
+        };
+
+    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?
+
+
+Copyright
+
+    This document has been placed in the public domain.
+
+
+
+Local Variables:
+mode: indented-text
+indent-tabs-mode: nil
+End: