On 07:42 pm, [EMAIL PROTECTED] wrote: >On 1/10/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> >><"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.
>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. I could not possibly agree more. 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. 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. 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.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
