Abstract

This PEP describes the procedure for changes to Python that arebackwards-incompatible between the Python 2.X series and Python 3000.All such changes must be documented by an appropriate Python 3000 PEPand must be accompanied by code that can identify when pieces ofPython 2.X code may be problematic in Python 3000.

Rationale

Python 3000 will introduce a number of backwards-incompatible changesto Python, mainly to streamline the language and to remove someprevious design mistakes. But Python 3000 is not intended to be a newand completely different language from the Python 2.X series, and itis expected that much of the Python user community will make thetransition to Python 3000 when it becomes available.

To encourage this transition, it is crucial to provide a clear andcomplete guide on how to upgrade Python 2.X code to Python 3000 code.Thus, for any backwards-incompatible change, two things are required:

• An official Python Enhancement Proposal (PEP)
• Code that can identify pieces of Python 2.X code that may beproblematic in Python 3000

Python Enhancement Proposals

Every backwards-incompatible change must be accompanied by a PEP.This PEP should follow the usual PEP guidelines and explain thepurpose and reasoning behind the backwards incompatible change. Inaddition to the usual PEP sections, all PEPs proposingbackwards-incompatible changes must include an additional section:Compatibility Issues. This section should describe what is backwardsincompatible about the proposed change to Python, and the major sortsof breakage to be expected.

While PEPs must still be evaluated on a case-by-case basis, a PEP maybe inappropriate for Python 3000 if its Compatibility Issues sectionimplies any of the following:

• Most or all instances of a Python 2.X construct are incorrect inPython 3000, and most or all instances of the Python 3000 constructare incorrect in Python 2.X.

  So for example, changing the meaning of the for-loop else-clausefrom “executed when the loop was not broken out of” to “executedwhen the loop had zero iterations” would mean that all Python 2.Xfor-loop else-clauses would be broken, and there would be no way touse a for-loop else-clause in a Python-3000-appropriate manner.Thus a PEP for such an idea would likely be rejected.

• Many instances of a Python 2.X construct are incorrect in Python3000 and the PEP fails to demonstrate real-world use-cases for thechanges.

  Backwards incompatible changes are allowed in Python 3000, but notto excess. A PEP that proposes backwards-incompatible changesshould provide good examples of code that visibly benefits from thechanges.

PEP-writing is time-consuming, so when a number ofbackwards-incompatible changes are closely related, they should beproposed in the same PEP. Such PEPs will likely have longerCompatibility Issues sections, however, since they must now describethe sorts of breakage expected fromall the proposed changes.

Identifying Problematic Code

In addition to the PEP requirement, backwards incompatible changes toPython must also be accompanied by code to issue warnings for piecesof Python 2.X code that will behave differently in Python 3000. Suchwarnings will be enabled in Python 2.X using a new command-lineswitch: -3. All backwards incompatible changes should beaccompanied by a patch for Python 2.X that, when -3 isspecified, issues warnings for each construct that is being changed.

For example, ifdict.keys() returns an iterator in Python 3000,the patch to the Python 2.X branch should do something like:

If -3 was specified, changedict.keys() to return asubclass oflist that issues warnings whenever you use anymethods other than__iter__().

Such a patch would mean that warnings are only issued when featuresthat will not be present in Python 3000 are used, and almost allexisting code should continue to work. (Code that relies ondict.keys() always returning alist and not a subclass shouldbe pretty much non-existent.)

References

TBD

Copyright

This document has been placed in the public domain.