[TransWarp] Re: Is there a problem with module Inheritance ??

[Phillip J. Eby]

At 05:56 PM 3/27/02 +0100, Ulrich Eck wrote:

>Hi Philip,
>
>i followed your example to use a specialist and found out the following:
>
>[bug report snipped]
>
>shouldn't the rebuilt classes be replaced by name in all modules ???
>
>or did i just get something wrong with module-inheritance ??

As you've probably seen by now, you found a bug.  To be precise, it was a 
minor design flaw; I didn't even think about effecting this sort of 
rebinding, which requires rebinding of the contents of classes as well as 
the bases.

Discussion of the bug with Ty led us to contemplate an entirely different 
architecture for module inheritance that would eliminate all the remaining 
"not what you expected" limitations, but it's too intensive of a rewrite 
for the 0.2 release cycle.  We did, however, come up with a set of rules 
that we can use to issue warnings for certain constructions.  For example, 
we can warn of mutables being modified at the global level, successive 
reassignments to names at the global level, and so on.  Unfortunately, the 
most "interesting" of these constructions aren't really warnable without 
doing certain kinds of block analysis on the bytecode, which is potentially 
quite expensive.

What's rather interesting, however, is that we found that module 
inheritance can actually be modeled in terms of threads or coroutines for 
each module's code, which yield to each other when they need or have values 
for each other.  This suggests that Stackless Python's microthreading would 
be ideal for this.  But I really don't want to make TransWarp require 
Stackless!

We thought of warping generators to our sick and twisted designs, but 
unfortunately they lack the necessary bidirectionality.  The only way to do 
what we want without threading or coroutines is to do block analysis on
the code, and we may have to do some degree of that even *with* threading 
or coroutines.

So, for 0.2, the current limitations of class rebinding will stay in 
place.  Specifically, the *only* places you get class rebinding are in 
another class' bases and dictionary.  (Until yesterday's fix, rebinding 
only took place on the bases.)