[Python-Dev] Gradual migration

[Paul Prescod]

"M.-A. Lemburg" wrote:
> 
>...
> 
> 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.

I disagree for a variety of reasons:

 * implementation language and Python inheritance semantics are almost
completely distinct. After all, we have Python implementations in a
variety of languages with minor incompatibilities. Python could have a
proper type/class merging even if it were written in assembly language.
So let's leave implementation language aside.

 * there is a hell of a lot we can do to make the type/class split less
visible without a major rewrite. For instance, lists could have a
__getitem__ method so that they "act like" instances. Instances could
return their methods in a dir() so that they "act like" built-in
objects. So there is no reason to wait for a complete rewrite to start
on this path.

 * It may even be the case that we can get from here to complete merged
type/class semantics WITHOUT a rewrite. If a mad genious had not written
stackless Python I would have sworn up and down that stackless Python
would require a Python rewrite. It didn't. If another slightly less mad
genious had not integrated ints and longs I would never have believed it
possible without another rewrite. Someone needs to do an analysis of
what it takes to merge types and classes and *demonstrate* that it
requires a rewrite rather than *asserting* that it requires a rewrite.

In other words, let's stop sprinkling the "major rewrite" pixie dust on
hard problems and instead decide where we want to go and how we want to
get there!

> 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.

I don't know what you mean by a "low-level strategy" for classes. It's
not like we can somehow use C++ vtables without giving up Python's
dynamicity. Python's class handling is about as low-level as it can get
in my humble opinion.

> 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.

Of course that's where we want to go but it doesn't avoid the backwards
compatibility problems. We can do this today using proxying.

> 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.

We can easily do this today.

> Dito for numbers (and division strategies).

There's no way I'm going to let you get away with that little sleight of
hand. How is inheritance holy water going to allow us to change the
semantics of:

5/2

without breaking code??

The same goes for

a.b = 5

versus

a.B = 5

C++ does not help. Inheritance does not help. Pluggable compilers do not
help. We *will* break code. We just need to decide whether to do it in a
thoughtful way that gives people a chance to migrate or put off
decisions until the last possible moment and then spring it on them with
no between-version upgrade path.

> 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.

When you change defaults you break code. Keeping the old functionality
around is barely helpful.  Nobody has EVER proposed a change to Python
where something that was previously possible is now made impossible. So
whatever our strategy, the PROBLEM is changing defaults. The solution is
telling people what defaults are changing in what timeline and
discouraging them from depending on the old defaults.

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

Sounds mythical. I'm trying to take it out of the realm of fluffy clouds
and bring it into the world that people can plan their businesses and
coding strategies around.
-- 
 Paul Prescod - Not encumbered by corporate consensus
Simplicity does not precede complexity, but follows it. 
	- http://www.cs.yale.edu/homes/perlis-alan/quotes.html