[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/)