This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author kostja
Recipients kostja
Date 2011-01-28.11:23:24
SpamBayes Score 5.1436633e-13
Marked as misclassified No
Message-id <1296213805.8.0.5306438252.issue11039@psf.upfronthosting.co.za>
In-reply-to
Content
I'm using a 64 bit system, but the issue is as well repeatable on 32 bit systems: 

kostja@shmita:~$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 0xffffffffffffffff
18446744073709551615L
>>> [0xffffffffffffffff]
[18446744073709551615L]
>>> str(0xffffffffffffffff)
'18446744073709551615'
>>> str([0xffffffffffffffff])
'[18446744073709551615L]'

Notice the 'L' specifier disappears when creating a string from an integer. I.e. depending on conversion order, 'L' specifier is present or absent in the resulting string representation.

I don't know the reason why 'L' specifier is necessary at all when printing integers, rather, I'd say it's very harmful, because makes Python program platform-dependent (since int is mapped to C long, 32-bit systems print 'L' where 64-bit systems don't), but please at least make the output consistent!

Thanks,
-- 
kostja
History
Date User Action Args
2011-01-28 11:23:25kostjasetrecipients: + kostja
2011-01-28 11:23:25kostjasetmessageid: <1296213805.8.0.5306438252.issue11039@psf.upfronthosting.co.za>
2011-01-28 11:23:24kostjalinkissue11039 messages
2011-01-28 11:23:24kostjacreate