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/)