forked from python/peps
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathpep-0237.txt
127 lines (82 loc) · 3.32 KB
/
pep-0237.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
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: