On 1/10/07, Raymond Hettinger
<"Anthony Baxter">
Comments? What else should get warnings?
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. By Guido's
plan, 3.0 will arrive well before 2.6, and the migration step is not as
large as many fear it to be. Having Python 2.6 optionally warn for
3.0-compatibility is a lot easier for the average developer than having a
separate tool or a separately compiled Python.
--
Thomas Wouters