Add suggestion by Doug Landauer -- use an instrumented Python 2.x to find
future problems.
This commit is contained in:
parent
03d1469fe6
commit
e4caee0c87
16
pep-3000.txt
16
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
|
||||
==================
|
||||
|
|
Loading…
Reference in New Issue