[Python-Dev] Int FutureWarnings and other 2.4 TODOs
Tim Peters
tim.one at comcast.net
Sat Nov 29 22:24:21 EST 2003
[Guido]
> ...
> (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, and especially since it looks like 2.3 is going to become the next 1.5.2
(i.e., the version everyone flocks to, and then badgers you about for the
next 20 years <wink>).
> (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.
+1. Changing string representations is always traumatic (lots of programs
rely on parsing them), and I have a hard time imagining what positive good
could come from stripping the 'L'. Making that change for str(long) seemed
like pure loss from my POV (broke stuff and helped nothing).
> Any comments on these? Should I update PEP 237 to reflect this?
The PEP should reflect The Plan, sure.
More information about the Python-Dev
mailing list