[Python-3000] Backward compatibility

[Brett Cannon]

On 3/23/06, Ian Bicking <ianb at colorstudy.com> wrote:
> Guido van Rossum wrote:
> >>I saw this too in the archives, and thought shit, that's going to mess
> >>up a lot of my code.  I would assume (though it's a separate point of
> >>discussion) that Python 3k should still try hard to keep backward
> >>compatibility.  Backward compatibility isn't a requirement, but it's
> >>still clearly a feature.
> >
> >
> > You seem to be misunderstanding what Python 3000 is. The whole point
> > of Python 3000 is to *not* be bound by backwards compatibility
> > constraints, but instead make the best decisions possible (without
> > making it a different language).
>
> I think this was in the bullet points of pending discussions, so maybe
> should be a separate thread.
>
> When I say it is a feature... I guess that seems obvious to me.  In 2.x
> backward compatibility is something of a requirement.  But in 3.0/3000
> backward compatibility is still a nice thing to have, that can be
> weighed against other nice things.  That doesn't seem overly
> constrained, just practical.
>

I don't think things are going to be broken gratuitously.  Just look
at the backlash against PEP 348.  The most common reason for not
wanting a change was not because a suggestion was bad, just that the
benefit of the change was outweighed by the breakage and pain of
transition.

I suspect all changes will be weighed this way and thus extreme
breakage will be done only in cases where a clear benefit exists. 
Plus we will have to all convert stdlib code over so we will have a
decent idea of what is needed in terms of guidellines or tools to make
the transition easier.

-Brett