[Python-Dev] flextype.c -- extended type system

[Christian Tismer]

Brett Cannon wrote:
> [Christian Tismer]
> 
> 
>>Hi Guido, py-dev,
>>
>>preface:
>>--------
>>a week ago or so, I sent a patch to Guido that removes
>>the "etype" struct. This is a hidden structure that
>>extends types when they are allocated on the heap.
>>One restriction with this type was that types could
>>not be extended by metatypes for some internal reason.
>>I fixed this. Now meta-types can define extra slots
>>for types.
> 
> I have never written a type or object in C, so bear with my newbie
> questions.  Are you saying, Chris, that before you could not inherit a
> type written in C and override a method?  Is this only in regards to the
> magic method slots or just any method?

Sure you could. The just was no general interface to it.
The magic method slots are already easy to override,
assuming that you always call these via the type slots
and don't call them directly.

For your own, non-magic methods, there was not support, yet.
Sure, you could override your methods, but you needed
extra machinery to keep track of the methods, to find out
which to call when, and so on.
The proper way to store extra info about methods is to
put this info into the type object itself. This was not
possible before my patch. You could help yourself my
extending some of the existing method tables, but this
is hackish.

With my flextype stuff, you explicitly extend your type
object with extra function pointers. Then you provide a
table with your implementation and wrapper functions,
and inheritance works from alone. That's what I was after.

> From what I gather in your email, it seems like you came up with proper
> overriding inheritence in C for methods defined in a type.  So does this
> means you can now override the __contains__ magic slot in C code through
> some inherited type and this was not doable before?  Perhaps an example of
> something from the Python core that was not possible before would solidify
> this for me.

I didn't care of the magic slots at all. I think they don't need
to be changed, but I will have a look at it.
The difference with my dynamic methods is that the method tables
are filled once, at the time when your type/class is created.
After that, there is no longer any lookup necessary. Method calls
which are not overridden are called with maximum possible speed.

In order to support changes to the undelying classes *after*
type creation, I will provide an extra type method that
allows to "re-bind" explictly.

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer@tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/