[Python-bugs-list] [Bug #123859] %[duxXo] long formats inconsistent

[noreply@sourceforge.net]

Bug #123859, was updated on 2000-Nov-29 14:38
Here is a current snapshot of the bug.

Project: Python
Category: Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Summary: %[duxXo] long formats inconsistent

Details: Guido, if you want me to do what I suggested, assign it back to me.

[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?

[Tim]
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>.


Follow-Ups:

Date: 2000-Nov-29 21:26
By: tim_one

Comment:
Closed.  test_format.py revision 1.3; NEWS 1.82; stringobject.c 2.94; unicodeobject.c 2.67.

Guido added, on Python-Dev:

I just skimmed the pipermail python-dev archives and found one item to pronounce on: what "%o" should do with negative longs.  I agree with Tim.  Also for "%x".  Reason: this matches oct() and hex().

>>> oct(-10L)
'-012L'
>>> oct(-10)
'037777777766'
>>> hex(-10L)
'-0xAL'
>>> hex(-10)
'0xfffffff6'
>>> 

Compatibility be damned (in this case).

(One could argue that for plain ints, the same result are desirable; however when these are used as bitmasks, I as human reader prefer to see '0xfffffff6' rather than '-0xA'.  Ah the insanity of consistency!)

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=123859&group_id=5470