Hi, While adding support to Jython for formatting of longs in "%[duxXo]", I inadvertently introduced another difference between Python and Jython: Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information.
print '%030o' % -10L 000000000000000000037777777766
Jython 2.0alpha1 on java1.3.0 (JIT: null) Type "copyright", "credits" or "license" for more information.
print '%030o' % -10L -00000000000000000000000000012
The CPython behaviour looks as if the number have been through a C long before it is formatted. It that intended? Would jython be wrong if it used the result above? regards, finn
Finn Bock writes:
Fred L. Drake, Jr. writes:
It doesn't look like either of them is doing the right thing!
Tim Peters writes:
[Fred scrutinizes everything very carefully again... blushes when he notices that this was the 'o' format code, not 'd', and quietly slinks off to walk the dog...] -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations
[Finn Bock]
Hard to say, but it is what the code does <wink>. In 1.5.2, "true longs" raised an error in this context, so the code first looked to see whether the putative Python long actually fit in a C long first; if so, it did not raise an error, and ran the value thru C long formatting instead (in stringobject.c): if (PyLong_Check(v) && PyLong_AsLong(v) == -1 && PyErr_Occurred()) { /* Too big for a C long. */ That test survived in 2.0; the difference is that it no longer raises an error if the value doesn't fit in a C long.
Would jython be wrong if it used the result above?
Hard to say! Since the size of a Python int varies across platforms, not even CPython will display the same thing for all Python longs across all platforms. I'm in favor of changing the test above to if (PyLong_Check(v)) { Then CPython will match JPython here, and CPython will produce the same result across all platforms when given a Python long. The downside is that it will not produce the same result as 2.0 (or earlier). Guido, you can Pronounce now <wink>.
Finn Bock writes:
Fred L. Drake, Jr. writes:
It doesn't look like either of them is doing the right thing!
Tim Peters writes:
[Fred scrutinizes everything very carefully again... blushes when he notices that this was the 'o' format code, not 'd', and quietly slinks off to walk the dog...] -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations
[Finn Bock]
Hard to say, but it is what the code does <wink>. In 1.5.2, "true longs" raised an error in this context, so the code first looked to see whether the putative Python long actually fit in a C long first; if so, it did not raise an error, and ran the value thru C long formatting instead (in stringobject.c): if (PyLong_Check(v) && PyLong_AsLong(v) == -1 && PyErr_Occurred()) { /* Too big for a C long. */ That test survived in 2.0; the difference is that it no longer raises an error if the value doesn't fit in a C long.
Would jython be wrong if it used the result above?
Hard to say! Since the size of a Python int varies across platforms, not even CPython will display the same thing for all Python longs across all platforms. I'm in favor of changing the test above to if (PyLong_Check(v)) { Then CPython will match JPython here, and CPython will produce the same result across all platforms when given a Python long. The downside is that it will not produce the same result as 2.0 (or earlier). Guido, you can Pronounce now <wink>.
participants (3)
-
bckfnn＠worldonline.dk -
Fred L. Drake, Jr. -
Tim Peters