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

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