<br><br><div><span class="gmail_quote">On 1/10/07, <b class="gmail_sendername">Raymond Hettinger</b> <<a href="mailto:raymond.hettinger@verizon.net">raymond.hettinger@verizon.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<"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>The Py2.x series may live-on for some time and should do so<br>as if Py3.x did not exist. Burdening the 2.x code with loads<br>of warnings will only clutter the source code and make maintenance<br>more difficult. There may also be some performance impact.
<br><br>We should resolve that Py2.6 remain as clean as possible<br>and that Py3.0 be kept in its own world. Forging a new<br>blade does not have to entail dulling the trusty old blade.</blockquote><div><br>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.
<br></div></div><br>-- <br>Thomas Wouters <<a href="mailto:thomas@python.org">thomas@python.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!