[Python-bugs-list] [ python-Bugs-591586 ] Get rid of etype struct

noreply@sourceforge.net noreply@sourceforge.net
Thu, 05 Sep 2002 04:31:52 -0700


Bugs item #591586, was opened at 2002-08-06 17:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591586&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Get rid of etype struct

Initial Comment:
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.

----------------------------------------------------------------------

>Comment By: Christian Tismer (tismer)
Date: 2002-09-05 13:31

Message:
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

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-09-03 20:12

Message:
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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591586&group_id=5470