From bff4d98e0354ce92474c4aceecac042ca0878be2 Mon Sep 17 00:00:00 2001 From: Guido van Rossum Date: Wed, 1 Aug 2001 16:48:28 +0000 Subject: [PATCH] Lots of updates, more rationale, explicit transition plan. --- pep-0237.txt | 221 ++++++++++++++++++++++++++++++++++----------------- 1 file changed, 146 insertions(+), 75 deletions(-) diff --git a/pep-0237.txt b/pep-0237.txt index 4033e953e..9913a565f 100644 --- a/pep-0237.txt +++ b/pep-0237.txt @@ -27,81 +27,45 @@ 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. + 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. + + 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.) + + 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. -Literals +Transition - 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. + 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. -Builtin Functions + 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). - 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: + 3. Long literals and (if we choose implementation plan 1 below) + the long() built-in are no longer legal. - long=int + We propose the following timeline: - at the top of the module, or: + 1. Python 2.2. - import __builtin__ - __builtin__.long=int + 2. The rest of the Python 2.x line. - 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<