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

[Guido van Rossum]

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