On Nov 8, 2007 6:18 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > On Nov 8, 2007 6:05 PM, Gregory P. Smith <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
