From e4caee0c8701ab3e1f63492c7afa166ce12c07ab Mon Sep 17 00:00:00 2001 From: Guido van Rossum Date: Thu, 6 Apr 2006 18:03:49 +0000 Subject: [PATCH] Add suggestion by Doug Landauer -- use an instrumented Python 2.x to find future problems. --- pep-3000.txt | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/pep-3000.txt b/pep-3000.txt index 4b7269f2e..ba9733422 100644 --- a/pep-3000.txt +++ b/pep-3000.txt @@ -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 ==================