[Python-3000] PEP 3002 (Procedure for Backwards-Incompatible Changes) (original) (raw)

Guido van Rossum guido at python.org
Thu Apr 27 23:43:21 CEST 2006

I just read PEP 3002 and while I like most of what I see (thanks Steven Bethard!) there's one section that stands out as problematic. I'm quoting it here:

""" Optional Extensions

Instead of the python3warn.py script, a branch of Python 3000 could be maintained that added warnings at all the appropriate points in the code-base. PEPs proposing backwards-incompatible changes would then provide patches to the Python-3000-warn branch instead of to python3warn.py. With such a branch, the warnings issued could be near-perfect and Python users could be confident that their code was correct Python 3000 code by first running it on the Python-3000-warn branch and fixing all the warnings.

At the moment, however, this PEP opts for the weaker measure (python3warn.py) as it is expected that maintaining a Python-3000-warn branch will be too much of a time drain. """

I believe that this is aiming at a similar idea I put in PEP 3000:

""" 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.) """

I expect that the PEP 3002 proposal won't quite work; a branch of Python 3000 to identify backwards incompatibilities would have a hard time parsing code that uses the Python 2.x features that are completely cut out of Python 3000, such as u"..." literals, or different except clause syntax, etc. Rather than a version of Python 3000, I suggest to add such warning code to Python 2.x, and not as a branch, but as a permanent feature (that is however only enabled by a command-line flag).

I suppose the PEP 3002 proposal was written with the assumption that a syntactic conversion would be doable purely mechanically, and that the semantic issues would be sorted out using a second phase tool. But I would rather see a single (integrated) tool that looks at unconverted 2.x code and suggests or makes all changes necessary. This would require a combination of techniques, but would be more useful to 2.x users.

I guess this would also affect the use of the python3warn.py script.

Perhaps Steven or someone else could propose specific edits to PEP 3002 to reflect this?

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list