[Python-Dev] Should hex() yield 'L' suffix for long numbers?

Mon Jun 12 21:37:01 CEST 2006

On 6/12/06, Tim Peters <tim.peters at gmail.com> wrote:
> [Guido]
> > Here's how I interpret PEP 237. Some changes to hex() and oct() are
> > warned about in B1and to be implemented in B2. But I'm pretty sure
> > that was about the treatment of negative numbers, not about the
> > trailing 'L'. I believe the PEP authors overlooked the trailing 'L'
> > for hex() and oct().
>> That was mentioned explicitly under "Incompatibilities" (last sentence):
>> - Currently, the '%u', '%x', '%X' and '%o' string formatting
> operators and the hex() and oct() built-in functions behave
> differently for negative numbers: negative short ints are
> formatted as unsigned C long, while negative long ints are
> formatted with a minus sign. This will be changed to use the
> long int semantics in all cases (but without the trailing 'L'
> that currently distinguishes the output of hex() and oct() for
> long ints). ...

Oops, I missed that.
> Since it wasn't mentioned explicitly again under "Transition", but the
> trailing 'L' on repr() was explicitly mentioned twice under
> "Transition", the least strained logic-chopping reading is that losing
> the 'L' for hex() and oct() was intended to be done along with the
> other changes in the paragraph quoted above.

I now agree with that.
> > I think they should be considered just as sticky as the trailing 'L' for repr().
>> Given that the "least strained" reading above missed its target
> release, and the purpose of target releases was to minimize annoying
> changes, I agree it should be left for P3K now regardless. I'll
> change the PEP accordingly to make this explicit.

Agreed again. Thanks for updating the PEP.
PS Tim: did you get my private email about SequenceMatcher?
-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)