[Python-Dev] Gradual migration

[M.-A. Lemburg]

Paul Prescod wrote:
> 
> 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 think will simply be a consequence of doing a complete rewrite
of the interpreter for Py3K. AFAIR, the only truely feasable
solution would be doing the rewrite in a widely portable
subset of C++ and then managing classes at that level.
 
Moving to a common and very low-level strategy for classes
will allows us to put even the most basic types (strings and
numbers) into an inheritence tree. 

Differences like the
ones between Unicode and 8-bit strings would then flesh
out as two different subclasses of a generic string type which
again is based on a generic sequence type.

The same could be done for dictionaries: special ones for
just string keys, case insensitive lookups, etc. could all
be subclasses of a generic mapping class.

Dito for numbers (and division strategies).

By following this principle there won't be all that much
breakage, since the old functionality will still be around,
only the defaults will have changed.

Add to this pluggable compilers and ceval loops, plus a nice
way of configuring the lot on a per-module basis and you're
set. (Ok, it's a fluffy clouds image, but you get the picture ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/