[Python-Dev] Int FutureWarnings and other 2.4 TODOs

Raymond Hettinger python at rcn.com
Sat Nov 29 19:38:25 EST 2003


> (1) PEP 237 promises that after the new semantics are introduced for
>     hex/oct literals and conversions, and left shifts, operations that
>     cause a different result than before will produce a warning that
>     is on by default.  Given the pain we've suffered through the
>     warnings in 2.3 about this stuff, I propose to forget about these
>     warnings.  The new semantics are clear and consistent, warnings
>     would just cause more distress, and code first ported to 2.3 will
>     already have silenced the warnings.

+1, The warnings cause more pain than they save.  Part of the purpose of
a warning is to leave you feeling unsettled -- I don't think that is a
worthy goal when the code is going to work fine anyway.

Let PyChecker or some such warn about prior version compatibility issues
like that.



> (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.

If there is transition difficultly, let it be a prompt to consider
applying the forthcoming Decimal module.

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.

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().



> Should I update PEP 237 to reflect this?

Yes, that's better than surprising people later.




Raymond




More information about the Python-Dev mailing list