[Python-3000] pre-PEP: Procedure for PEPs with Backwards-Incompatible Changes

[Brett Cannon]

On 3/27/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> The (pre-)PEP should be mostly self-explanatory.  I'm trying to lay
> down some guidelines for how backwards-incompatible changes should be
> introduced in Python 3000.  Feedback is greatly appreciated,
> especially in the Identifying Correct Code section.
>
>
> PEP: XXX
> Title: Procedure for PEPs with Backwards-Incompatible Changes
> Version: $Revision$
> Last-Modified: $Date$
> Author: Steven Bethard <steven.bethard at gmail.com>
> Status: Draft
> Type: Informational
> Content-Type: text/x-rst
> Created: 03-Mar-2006
> Post-History: 03-Mar-2006
>
>
> Abstract
> ========
>
> This PEP describes the procedure for changes to Python that introduce
> backwards incompatible changes between the Python 2.X series and
> Python 3000. All such changes must be documented by an appropriate
> Python 3000 PEP and must be accompanied by code that can identify
> when pieces of Python 2.X code will be incorrect in Python 3000.
>
>
> Rationale
> =========
>
> Python 3000 will introduce a number of backwards-incompatible changes
> to Python, mainly to streamline the language and to remove some
> previous design mistakes. But Python 3000 is not intended to be a new
> and completely different language from the Python 2.X series, and it
> is expected that much of the Python user community will make the
> transition to Python 3000 when it becomes available.
>
> To encourage this transition, it is crucial to provide a clear and
> complete 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 will be
>   incorrect in Python 3000
>

Requiring code that can identify things in 2.x that will change in 3.0
that are coded externally from the interpreter is going to be *really*
difficult in some situations, if not impossible to get right.  Just
look at dict.items(); how do you do that?  You can't just assume any
object in a function that was passed in and has a items method called
on it is a dict.  But if you don't you can only detect for local scope
(assuming you do a type inference for the code block).

I say documenting where code will break and provide any possible
transition strategy for people with code that will be affected is the
best we can do in terms of requiring stuff.  If you can provide code
to detect the problem, great; but don't make it a base requirement for
every change.

-Brett