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

Guido van Rossum guido at python.org
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/)

More information about the Python-Dev mailing list