[Python-Dev] hex() and oct() still include the trailing L - change this in 2.6?

[Guido van Rossum]

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/)