I've got the first version of a patch against the current CVS tree
to treat ints and longs identically at the Python programmer's level:
ftp://starship.python.net/pub/crew/amk/new/long-python-patch-1
As an acid test, this patch changes PyInt_FromLong() to just call
PyLong_FromLong(). After some minor changes to the test suite to skip
tests of OverflowError, and to account for the string representation
of integers having an 'L' on the end, Python gets through the
test_builtin test suite. (test_pickle and test_cpickle fail with this
aggressive patch; I won't bother to fix that.) Obviously, these
changes won't be in any final version.
The patch adds a new API function:
extern DL_IMPORT(int) PyIntOrLong_AsLong Py_PROTO((PyObject *, long *));
It returns -1 if the PyObject is a long integer that's too large to
fit into a C long, so it's used like this:
if (PyIntOrLong_AsLong(fno, &value)) {
PyErr_SetString(...
The pystone results are puzzling; original Python gets 3154.57
pystones on my machine, and the patched version without PyInt_FromLong
returning longs gets a spurious value of 3367! With the
PyInt_FromLong change, it gets 2450.98 pystones, which is what you'd
expect.
Mostly I want comments on the approach, and am not claiming this
version is reliable. Still to do:
* Write test cases that exercise the new code.
* Start converting Python/structmember.c, and a bunch of files
in Modules/
* Begin changing places that raise OverflowError, to create long
integers instead. (Or maybe this is a bad idea; certainly it might
break existing code.)
--
A.M. Kuchling http://starship.python.net/crew/amk/
I'm an excuse for medical experiments and art theory. You must get me out of
here and out of the hospital.
-- Peter Greenaway, _A Zed and Two Noughts_ (1986)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4