<html><body>On 07:42 pm, thomas@python.org wrote:<br />>On 1/10/07, Raymond Hettinger <raymond.hettinger@verizon.net> wrote:<br />>><br />>><"Anthony Baxter"><br />>> > Comments? What else should get warnings?<br />>><br />>>It is my strong preference that we not go down this path.<br />>>Instead, the 2.6 vs 3.0 difference analysis should go in an<br />>>external lint utility.<br /><br />>Having Python 2.6 optionally warn for<br />>3.0-compatibility is a lot easier for the average developer than having a<br />>separate tool or a separately compiled Python.<br /><br />I could not possibly agree more.<br /><br />Given the highly dynamic nature of Python, such a tool will *at best* catch only the most egregious uses of deprecated features.  Backticks are easy enough to find, but the *only* way that I can reasonably imagine migrating a body of code like Twisted (or any non-trivial Python library) would be having a way to examine the warning output of its test suite.<br /><br />I am suuuuper +1 on the warnings for 2.6, as well as forward-compatibility at some point in the 2.x series for new syntax.  Without the ability to bridge 2.x->3.0 during some interim period, I can say for sure that Twisted _will not_ migrate to 3.0, ever.  We are really a small project and just don't have the manpower to maintain two overlapping but mutually incompatible codebases.<br /><br />I've been assuming for some time that the only hope for Py3k compatibility within Twisted would be using PyPy as a translation layer.  With the addition of runtime compatibility warnings, it might be feasible that we could run on the "bare metal" (ha ha) of Python3's VM.<br /></body></html>