(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.
-0, The reasons are good but this one has been promised for several years. It's time for an L free python -- one less thing to have to learn.
Yes, but people using type() or isinstance() or __class__ will still have to remember that there are two types of integers: int and long. And both built-ins will be with us for years, and they aren't quite aliases for each other (long('12') returns a long, but int('12') an int).
If there is transition difficultly, let it be a prompt to consider applying the forthcoming Decimal module.
This I don't understand.
If necessary, we could add a debug mode switch for L's to be on or off. By putting it the debug build, we keep people from using it in production code. The purpose is to allow code to be run twice to see if different results are obtained.
But making a debug build is far from trivial (especially on Windows). Perhaps it should be a switch on the regular build but also produce a warning, to annoy. :-)
Also, we can put migration advice in PEP 290 and whatsnew24.tex to grep for indicators like [:-1] on the same line as long() or repr().
Can you take care of that?
Should I update PEP 237 to reflect this?
Yes, that's better than surprising people later.
I'll do that (in due time). --Guido van Rossum (home page: http://www.python.org/~guido/)