[New-bugs-announce] [issue11039] Use of 'L' specifier is inconsistent when printing long integers

Konstantin Osipov report at bugs.python.org
Fri Jan 28 12:23:25 CET 2011

New submission from Konstantin Osipov <kostja.osipov at gmail.com>:

I'm using a 64 bit system, but the issue is as well repeatable on 32 bit systems: 

kostja at 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
>>> [0xffffffffffffffff]
>>> str(0xffffffffffffffff)
>>> str([0xffffffffffffffff])

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!


components: None
messages: 127284
nosy: kostja
priority: normal
severity: normal
status: open
title: Use of 'L' specifier is inconsistent when printing long integers
versions: Python 2.6

Python tracker <report at bugs.python.org>

More information about the New-bugs-announce mailing list