On 1/10/07, Thomas Wouters <thomas at python.org> wrote: > On 1/10/07, Raymond Hettinger <raymond.hettinger at verizon.net> wrote: > > It is my strong preference that we not go down this path. > > Instead, the 2.6 vs 3.0 difference analysis should go in an > > external lint utility. > > > > The Py2.x series may live-on for some time and should do so > > as if Py3.x did not exist. Burdening the 2.x code with loads > > of warnings will only clutter the source code and make maintenance > > more difficult. There may also be some performance impact. > > > > We should resolve that Py2.6 remain as clean as possible > > and that Py3.0 be kept in its own world. Forging a new > > blade does not have to entail dulling the trusty old blade. > > The idea is that we only generate the warnings optionally, only for things > that can be written in a manner compatible with prevalent Python versions, > and in the most efficient manner we can manage, *except* for the few things > that are already considered (by many) criminal to use: input(), backtics, > mixed tabs and spaces. In other words, for any code written even remotely > sane in the last five years, no extra warnings will be generated. I'd rather see this effort invested in a tool like Guido's 2to3, rather than in sprinkling warnings all through the 2.x codebase (even if they are wrapped in #ifdef's). I don't imagine people developing day-to-day in a 2.x environment are going to be so terribly interested in "is this 3.x compliant?" that downloading a separate tool would be an undue burden. Collin Winter
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