Add suggestion by Doug Landauer -- use an instrumented Python 2.x to find

future problems.
This commit is contained in:
Guido van Rossum 2006-04-06 18:03:49 +00:00
parent 03d1469fe6
commit e4caee0c87
1 changed files with 13 additions and 3 deletions

View File

@ -72,9 +72,10 @@ Compatibility and Transition
We need a meta-PEP to describe the compatibility requirements. Python
3000 will break backwards compatibility. There is no requirement that
Python 2.9 code will run unmodified on Python 3.0. I'm not sure
whether it is reasonable to require that Python 2.x code can be
mechanically translated to equivalent Python 3.0 code; Python's
Python 2.9 code will run unmodified on Python 3.0.
I'm not sure whether it is reasonable to require that Python 2.x code
can be mechanically translated to equivalent Python 3.0 code; Python's
dynamic typing combined with the plans to change the semantics of
certain methods of dictionaries, for example, would make this task
really hard. However, it would be great if there was some tool that
@ -82,6 +83,15 @@ did at least an 80% job of translation, pointing out areas where it
wasn't sure using comments or warnings. Perhaps such a tool could be
based on something like Pychecker.
Another kind of tool could be an instrumented version of 2.x which
produces run-time warnings about constructs that will get a different
meaning in 3.0. This can't be used for all incompatibilities, but
it's likely to help reach a larger percentage of correct translations.
(This approach is already in place for detecting reliance on '/' to do
integer division; see Tools/scripts/fixdiv.py, which finds occurrences
of int/int and long/long that were flagged by running your program
with -Qwarnall.)
Meta-Contributions
==================