[Python-Dev] Gradual migration

[Guido van Rossum]

> I want to focus on "3" -- breakage. Rather than delaying painful
> backwards-compatibility breakage I thing we should make it less painful.
> We should decide where we are going long before we ask our users to move
> there. I think we should start including alternatives to syntaxes and
> features that we know are broken. Once people move to the alternatives
> we can "reassign" or remove the original syntax with much less pain.

Absolutely.  Whenever possible, we should try to plan for migration in
Python 2.x.

> In other words, rather than telling people "here's a new version, your
> code is broken, sorry." We should tell them: "we're going to break code.
> Here's an alternative syntax that you can use that will be interpreted
> the same in the old and new versions -- please move to this new syntax
> as quickly as possible."

It would also help if we could produce automatic translation tools
that will convert the old syntax into the new.  This desire may
restrict our choices however: the translation tools don't have runtime
information to go by.  It's easy enough to change obsolete syntax into
new syntax, but it's hard to decide whether a particular "/" operator
should be changed into an integer divide ("//") or left alone.

> I'll outline some examples of the strategy. You may or may not like
> details of the particular proposals but you might still agree with the
> strategy. Also, I don't claim that all of the proposals are fully
> fleshed-out...again, it's the strategy I'm most interested in. I don't
> even agree with every feature change I describe below -- they are just
> some I've heard of for Python 3000. In other words ** this is not a
> design document for Python 3000! **

I think the proper approach is to start a separate migration process
for each of these proposed changes.  Each should be paced separately
(the pace may depend on how hard to swallow the change is for users as
well as how hard it is to implement the new functionality) and for
each, a separate PEP in the 3000 series should be started.  I can even
see that several PEPs will be needed in some cases (e.g. one to
describe the new syntax, one to to flesh out the implementation, and
one to decide on the migration steps).

I won't comment on Paul's examples, that's for the various PEP
processes.

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