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

[Tim Peters]

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