[Python-Dev] hex() and oct() still include the trailing L - change this in 2.6?
Guido van Rossum
guido at python.org
Fri Nov 9 04:17:36 CET 2007
On Nov 8, 2007 6:18 PM, Brett Cannon <brett at python.org> wrote:
> On Nov 8, 2007 6:05 PM, Gregory P. Smith <greg at krypto.org> wrote:
> > I thought the hell of stripping trailing Ls off of stringed numbers was gone
> > but it appears that the hex() and oct() builtins still leave the trailing
> > 'L' on longs:
> > Python 2.6a0 (trunk:58846M, Nov 4 2007, 15:44:12)
> > [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> x = 0xffffffffc10025be
> > >>> x
> > 18446744072652596670L
> > >>> str(x)
> > '18446744072652596670'
> > >>> hex(x)
> > '0xffffffffc10025beL'
> > >>> '0x%x' % (x)
> > '0xffffffffc10025be'
> > >>> oct(x)
> > '01777777777770100022676L'
> > This appears to be fixed in py3k (as there is no longer an int/long to
> > distinguish). Can we at least get rid of the annoying L in 2.6?
> It will break code, so probably not. Consider this motivation to move
> over to Python 3.0. =)
Right. Or perhaps in some kind of forward compatibility mode. A future
import might do: from __future__ import no_long_suffix perhaps.
Reminder (I can't say this enough): Python 2.6 needs to be as close as
possible to 2.5, only adding forward compatibility with 3.0 as an
option (using either a command line flag or a future import depending
on what feature we're talking about).
Additions and improvements are fine of course; but deletions or
changes "in anticipation of 3.0" should not occur by default, only
when a specific forward compatibility feature is requested.
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev