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

[Tim Peters]

[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). ...

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 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.