The 'etype' struct in typeobject.c prevents people like
David Abrahams and Christian Tismer from defining
C-level metatypes that add slots to the end of the type
structure. It should be possible for type_new() to
place the additional structures after an offset
determined by tp_basicsize of the metatype, rather than
at a fixed offset.

Logged In: YES 
user_id=105700

Hi Guido,
I think I have a solution for this one, see the attached diff.
I did what you suggested: Make the adressing of the
members dependant from the metatype.
The etype struct has lost its members[1] field, to make it
easier to extend the structure. Instead, the allocator always
adds one to the size, to have the sentinel in place.

I did not yet publish the etype stucture, since I didn't find
a good name and place for it.
Testing was also not very thorow. I just checked that types
work from Python and that I can add __slots__ to them.
Will re-port this stuff to my Py2.2 Stackless base and try it
out as base type for my own C types.

ciao - chris

Logged In: YES 
user_id=105700

Hi again,
I fixed a minor bug/omission in my patch.
Also, the etype struct is now gone. Instead,
there is a PyHeaptypeObject definition in object.h
which simply can be used in your own extended
type definition like this:

struct _mytype = {
  PyHeaptypeObject etype;
  int field1;
  PyObject *something;
  char and_so_on[20];
}

But I'm quite convinced that this is not the end of the story.
I would like to solve the issue about how to efficiently call
object methods from C which might be overridden?
I believe we could provide an extension to heap types that
handles this automatically. I'm working on a prototype.

ciao - chris

Logged In: YES 
user_id=6380

Done, see SF patch 696193.