From 3206040dafaf62623e8dc50702e4bd113170c64f Mon Sep 17 00:00:00 2001 From: Guido van Rossum Date: Tue, 14 Aug 2001 18:12:48 +0000 Subject: [PATCH] Completely revamped. Pick implementation plan 2. Propose to do the easy bit in 2.2, the rest (introducing incompatibilities) in following releases. --- pep-0237.txt | 269 +++++++++++++++++++++++++-------------------------- 1 file changed, 134 insertions(+), 135 deletions(-) diff --git a/pep-0237.txt b/pep-0237.txt index 9913a565f..17243f36f 100644 --- a/pep-0237.txt +++ b/pep-0237.txt @@ -11,66 +11,43 @@ 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. + Python currently distinguishes between two kinds of integers + (ints): regular or short ints, limited by the size of a C long + (typically 32 or 64 bits), and long ints, which are limited only + by available memory. When operations on short ints yield results + that don't fit in a C long, they raise an error. There are some + other distinctions too. This PEP proposes to do away with most of + the differences in semantics, unifying the two types from the + perspective of the Python user. Rationale + Many programs find a need to deal with larger numbers after the + fact, and changing the algorithms later is bothersome. It can + hinder performance in the normal case, when all arithmetic is + performed using long ints whether or not they are needed. + Having the machine word size exposed to the language hinders portability. For examples Python source files and .pyc's are not - 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. + portable between 32-bit and 64-bit machines because of this. 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.) + An example is memory allocation, which explicit in C but automatic + in Python, giving us the convenience of unlimited sizes on + strings, lists, etc. It makes sense to extend this convenience to + numbers. 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. -Transition - - 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. - - 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). - - 3. Long literals and (if we choose implementation plan 1 below) - the long() built-in are no longer legal. - - We propose the following timeline: - - 1. Python 2.2. - - 2. The rest of the Python 2.x line. - - 3. Python 3.0 (at least two years in the future). - - Implementation - There are two alternative implementations to choose from. + Initially, two alternative implementations were proposed (one by + each autor): 1. The PyInt type's slot for a C long will be turned into a @@ -82,10 +59,10 @@ Implementation } 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. + 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 when a @@ -97,98 +74,135 @@ Implementation 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. + After some consideration, the second implementation plan was + selected, since it is far easier to implement, is backwards + compatible at the C API level, and in addition can be implemented + partially as a transitional measure. -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 +Incompatibilities 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. + for short and for long integers, and one or the other will have to + be changed somehow. This is intended to be an exhaustive list. + If you know of any other operation that differ in outcome + depending on whether a short or a long int with the same value is + passed, please write the second 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). + short int. This will be changed to return a long int instead. + The following operators can currently raise OverflowError: x+y, + x-y, x*y, x**y, divmod(x, y), x/y, x%y, and -x. (The last four + can only overflow when the value -sys.maxint-1 is involved.) - - Currently x<