[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