New submission from Konstantin Osipov <kostja.osi...@gmail.com>: 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 ---------- 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 <rep...@bugs.python.org> <http://bugs.python.org/issue11039> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
