[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4