[Python-Dev] Gradual migration

[Paul Prescod]

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