[Python-Dev] Int FutureWarnings and other 2.4 TODOs

[Guido van Rossum]

[me]
> > (2) PEP 237 promises that repr() of a long should no longer show a
> >     trailing 'L'.  This is not yet implemented (i.e., repr() of a long
> >     still has a trailing 'L').  First, past experience suggests that
> >     quite a bit of end user code will break, and it may easily break
> >     silently: there used to be code that did str(x)[:-1] (knowing x
> >     was a long) to strip the 'L', which broke when str() of a long no
> >     longer returned a trailing 'L'.  Apparently some of this code was
> >     "fixed" by changing str() into repr(), and this code will now
> >     break again.  Second, I *like* seeing a trailing L on longs,
> >     especially when there's no reason for it to be a long: if some
> >     expression returns 1L, I know something fishy may have gone on.

[Aahz]
> That makes sense to me; there should be an easy way from Python to
> detect what kind of object you've got (as a string representation), and
> repr() is precisely the place for it.

OK.  I've got one weak (-0 from Raymond) opposition to this idea, and
two strong agreements (+1 from Tim and Aahz), so I'm going to go ahead
and make this change to the PEP.  This pretty much makes PEP 237
finished except for the complete and utter eradication of the trailing
'L' (and probably of the 'long' type altogether) in Python 3.0.

--Guido van Rossum (home page: http://www.python.org/~guido/)