[Python-Dev] long formatting

Tim Peters tim_one@email.msn.com
Wed, 29 Nov 2000 17:32:29 -0500


[Finn Bock]
> 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?

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>.