Python 3K. It is the repository for our hopes and dreams. We tend to invoke it in three different situations: 1. in delaying discussions of gee-whiz features (e.g. static type checking) 2. in delaying hairy implementation re-factoring that we don't want to undertake right now. 3. in delaying painful backwards-compatibility breakage I think it is somewhat debatable whether we really need to or should do these three things all at once but that's a separate discussion for another day. (the other experiment may inform our decision) 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. 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." 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! ** Separating byte arrays from strings: 1. immediately introduce two new functions: binopen("foo").read() -> byte array stropen("foo","UTF-8".read() -> u"...." 2. warn about string literals that have embedded non-Unicode characters 3. deprecate extension modules that return "old fashioned" string arrays 4. after a period where all strings have been restricted to Unicode-compatibility, merge the Unicode and string types. 5. deprecate the special Unicode u"" syntax as an imperialist anachronism Reclaiming the division operator from truncating integer division: 1. immediately introduce new functions: div() that does division as we wish it was. 2. add a warning mode to Python (long overdue) 3. with the warning mode on, old-fashioned division triggers a deprecation warning. 4. after three years as a warning situation we expect all in-use Python scripts to have been upgraded to use the new operations and to explicitly truncate integer division when that is what is wanted. 5. at that point we can re-assign the division operator to be a floating point division if we wish. Case insensitivity: 1. Warn whenever a module or class has two __dict__ entries that differ only by case 2. Eventually, disallow that form of name-clash altogether 3. After a period, allow case variations to be equivalent. Unifying types and classes (more vague): 1. Add something like extension class to make type subclassing easier. 2. Informally deprecate modules that do not incorporate it. 3. Replace or fix details of the language and implementation that behave differently for types and classes. (e.g. the type() operator) -- Paul Prescod - Not encumbered by ActiveState consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html