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

Tim Peters tim.peters at gmail.com
Mon Jun 12 21:05:29 CEST 2006

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

More information about the Python-Dev mailing list