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)
[A.M. Kuchling]
It's a darned interesting question! This is the kind of thing I was worried about. I have a lot of int code in try blocks that catches OverflowError, but, when it happens, I redo the whole darn algorithm from scratch after promoting oodles of stuff to long! This is in situations where I expect that faster int arithmetic will usually work, but don't mind slower long arithmetic when necessary. All that would still work fine (it simply wouldn't trigger OverflowError anymore). Note this is done routinely in Demo/classes/Rat.py (which isn't mine, so I'm not the only one <wink>). At least a dozen copies of this are floating around my modules: def chop(n, int=int): """Return int(n) if no overflow, else n. """ try: return int(n) except OverflowError: return n This is usually just to get rid of the trailing "L" in output whenever possible, and sometimes to speed later operations. Etc. I think all my code would work fine. But then there's Guido's faqwiz.py: try: cutoff = now - days * 24 * 3600 except OverflowError: cutoff = 0 The intent there isn't at all obvious, although in context I think it would continue to work. After a quick but not entirely careless scan, I didn't see anything in the std distribution that's likely to break other than the OverflowError tests. It would usually *allow* rewriting to simpler, clearer, and probably faster (if long ops automagically cut back small-enough results to internal ints) code. glad-i'm-not-the-dictator<wink>-ly y'rs - tim
[A.M. Kuchling]
It's a darned interesting question! This is the kind of thing I was worried about. I have a lot of int code in try blocks that catches OverflowError, but, when it happens, I redo the whole darn algorithm from scratch after promoting oodles of stuff to long! This is in situations where I expect that faster int arithmetic will usually work, but don't mind slower long arithmetic when necessary. All that would still work fine (it simply wouldn't trigger OverflowError anymore). Note this is done routinely in Demo/classes/Rat.py (which isn't mine, so I'm not the only one <wink>). At least a dozen copies of this are floating around my modules: def chop(n, int=int): """Return int(n) if no overflow, else n. """ try: return int(n) except OverflowError: return n This is usually just to get rid of the trailing "L" in output whenever possible, and sometimes to speed later operations. Etc. I think all my code would work fine. But then there's Guido's faqwiz.py: try: cutoff = now - days * 24 * 3600 except OverflowError: cutoff = 0 The intent there isn't at all obvious, although in context I think it would continue to work. After a quick but not entirely careless scan, I didn't see anything in the std distribution that's likely to break other than the OverflowError tests. It would usually *allow* rewriting to simpler, clearer, and probably faster (if long ops automagically cut back small-enough results to internal ints) code. glad-i'm-not-the-dictator<wink>-ly y'rs - tim
participants (2)
-
A.M. Kuchling -
Tim Peters