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

Tim Peters tim.peters at gmail.com
Mon Jun 12 05:11:46 CEST 2006

[Ka-Ping Yee]

I did this earlier:

>>> hex(9999999999999) '0x9184e729fffL' and found it a little jarring, because i feel there's been a general trend toward getting rid of the 'L' suffix in Python. Literal long integers don't need an L anymore; they're automatically made into longs if the number is too big. And while the repr() of a long retains the L on the end, the str() of a long does not, and i rather like that. So i kind of expected that hex() would not include the L either. I see its main job as just giving me the hex digits (in fact, for Python 3000 i'd prefer even to drop the '0x' as well), and the L seems superfluous and distracting. What do you think? Is Python 2.5 a reasonable time to drop this L?

As I read pep 237, that should have happened in Python 2.3 or 2.4. This specific case is kinda muddy there. Regardless, the only part that was left for Python 3 was "phase C", and this is phase C in its entirety:

C. The trailing 'L' is dropped from repr(), and made illegal on input. (If possible, the 'long' type completely disappears.)

It's possible, though, that hex() and oct() were implicitly considered to be variants of repr() for purposes of phase C. How much are we willing to pay Guido to Pronounce?

More information about the Python-Dev mailing list