> Consistency and compatibility with > 3.0 suggest that they should return long for every new type we add > them to. What does the list think? I think Py2.6 and Py2.5 should be treated with more respect. Will backporting this change can only cause relief or create headaches?. By definition, the Py3.0 release was supposed to be the one big incompatible set of changes. Backporting with a goal of "consistency and compatibility with 3.0" suggests that the backporters may have lost their compass. FWIW, Py2.6 hasn't been released yet and no one *has* to upgrade to it. So, if it is to have any chance of success, it needs to be a better Python than 2.5. IMO, jamming 3.0 junk into 2.x just provides an incentive to skip the upgrade altogether. In the press release for 2.6, we need to be able to say something stronger than: filled with deprecations, two ways to do everything, dozens of tiny incompatibilities all done in the name of 3.0, and runs slower. I think there ought to be a much more agressive standard for 3.0 backports:, "does the proposed backport make 2.6 more attractive?" Remember, for large code bases, upgrading is a PITA (I think Google is still running tons of code on 2.2, 2.3, and 2.4). There needs to be a good incentive for upgrading; otherwise, Py2.6 *will* fail. The specific change suggested here is possibly (and perhaps probably) harmless; however, it is part of a larger trend that is not healthy for the 2.x series. Raymond
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