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

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 mailing list