[Python-Dev] Int FutureWarnings and other 2.4 TODOs

Guido van Rossum guido at python.org
Sat Nov 29 19:06:21 EST 2003

> [Guido van Rossum]
> > There's a bunch of FutureWarnings e.g. about 0xffffffff<<1 that
> > promise they will disappear in Python 2.4.  If anyone has time to
> > fix these, I'd appreciate it.  (It's not just a matter of removing
> > the FutureWarnings -- you actually have to implement the promised
> > future behavior. :-) I may get to these myself, but they're not
> > exactly rocket science, so they might be a good thing for a
> > beginning developer (use SF please if you'd like someone to review
> > the changes first).

[Kalle Svensson]
> I've submitted a patch (http://python.org/sf/849227).  And yes,
> somebody should probably take a good look at it before applying.  The
> (modified) test suite does pass on my machine, but that's all.  I may
> well have forgotten to add tests for new special cases, and I'm not
> the most experienced C programmer on the block either.

Well, it looks like you got everything right.  Congratulations!  I've
checked your code into CVS.

There are now two pieces of PEP 237 unimplemented (apart from the
complete and total eradication of long literals, which won't happen
until 3.0).

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

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

Any comments on these?  Should I update PEP 237 to reflect this?

> As a side note, I think that line 233 in Lib/test/test_format.py
>   if sys.maxint == 2**32-1:
> should be
>   if sys.maxint == 2**31-1:
> but I didn't include that in the patch or submit a bug report.
> Should I?

Fixed that too.  But somebody might want to backport it to 2.3.3.

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

More information about the Python-Dev mailing list