[Thomas Wouters] > 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.
If 3.0 comes out before Py2.6, ISTM that the authorative tool for checking Py3.0 compatibility is to simply run the code in Py3.0. Anything less is sure to miss something. Also, the usual reasons apply for having a stand-alone pychecker/pylint tool or module. As a separate tool, we can make rapid updates, add new tests, fix bugs, and enhance this usability of the tool in response to user feedback. One other thought is that warnings framework may not be the best way for a developer to go about updating his or her code. For me the warnings framework has almost never been of use for code updates.. It is easier and more comprehensive to grep for backticks or for calls to "coerce" than to run code and hope that every code path gets exercised. Raymond _______________________________________________ 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
