[Python-checkins] CVS: python/nondist/peps pep-0237.txt,1.5,1.6
Guido van Rossum
gvanrossum@users.sourceforge.net
Wed, 01 Aug 2001 09:48:30 -0700
Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv21608
Modified Files:
pep-0237.txt
Log Message:
Lots of updates, more rationale, explicit transition plan.
Index: pep-0237.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0237.txt,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** pep-0237.txt 2001/07/29 09:48:51 1.5
--- pep-0237.txt 2001/08/01 16:48:28 1.6
***************
*** 28,69 ****
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.
--- 28,130 ----
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.
+ 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.
+ 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.
+
+ 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 when a
+ result cannot be represented as a short int. A new type,
+ integer, may be introduced that is an abstract base type of
+ which both the int and long implementation types are
+ subclassed. This is useful so that programs can check
+ integer-ness with a single test:
+
+ 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.
+
+
+ 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.)
***************
*** 76,82 ****
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
--- 137,152 ----
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
+
The following operations have (usually subtly) different semantics
for short and for long integers, and one will have to change
***************
*** 92,96 ****
- 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'
--- 162,174 ----
- 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 0xffffffffL which is 2**32-1.
!
! - Currently, the '%u', '%x' and '%o' string formatting operators
! and the hex() and oct() built-in functions behave differently
! for negative numbers: negative short ints are formatted as
! unsigned C long, while negative long ints are formatted with a
! minus sign. The long int semantics will rule (but without the
! trailing 'L' that currently distinguishes the output of hex()
! and oct() for long ints).
- Currently, repr() of a long int returns a string ending in 'L'
***************
*** 98,129 ****
- 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.
--- 176,184 ----
- Currently, an operation with long operands will never return a
! short int. This may change (it allows an optimization). This
! is only relevant if implementation plan 2 is chosen.
- Currently, type(x) may reveal the difference between short and
! long ints. This will change if implementation plan 1 is chosen.
***************
*** 133,154 ****
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.
--- 188,225 ----
from PyFixNum and PyBigNum.
+ (Question for the Jython developers -- do you foresee any other
+ problems?)
+
Open Issues
! We expect that these issues will be resolved over time, as more
! feedback is received or we gather more experience with the initial
! implementation.
! - Which implementation plan to choose? Moshe is for plan 1, Guido
! is for plan 2. Plan 2 seems less work. Plan 1 probably breaks
! more at the C API level, e.g. PyInt_AS_LONG below.
! - What to do about sys.maxint? (If implementation plan 1 is
! chosen, it should probably be phased out; for plan 2, it is
! still meaningful.)
! - What to do about PyInt_AS_LONG failures? (Only relevant with
! implementation plan 1.)
! - What do do about %u, %o, %x formatting operators?
! - Should we 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 implementation? (Yes, it allows a common base
! class.)
!
! - Define an C API that can be used to find out what the
! representation of an int is (only relevant for implementation
! plan 1).