Newstyle Types Confounding!

Pete Shinners pete at shinners.org
Wed Jun 23 08:39:17 CEST 2004


I've been spending the last few night upgrading some 'classic' type 
objects to the more modern 'newstyle' types. Unless I am not finding 
some important page, this entire process is almost entirely 
undocumented. I've found the "Noddy" example, which was a helping start. 
But Noddy only gets you halfway there, and where it leaves off there is 
no further assistance.

I've been using the builtin Python types source as example, but this 
isn't answering most of my larger problems. Especially as the builtin 
types seem inconsistent in how they do thing. I have a few questions and 
am hoping to get a little guidance from those who understand this 
process better.


First, I have found no comfortable way to create new type instances from 
the C api. My types are wrappers for existing C structures. Originally 
my code called PyObject_New and filled out the structure data. This 
appears to be invalid with newstyle types, but I cannot discover the new 
method. It appears there is no standard since all the builtin types do 
this differently. I've ended up with something like this..

self = (PyMineObject*)PyMine_Type.tp_new(&PyMine_Type, NULL, NULL);

Can this be serious? This is the first time I've ever had to dig into 
the big Type structure to access function pointers. I find this to be 
disturbing, but I can learn to accept it if someone confirms this is the 
way to allocate newstyle type instances.


My second problem has to do with weakrefs. Again I cannot locate actual 
documentation on this, and the Noddy example ends before discussing 
weakrefs. I've created the PyObject* weakreflist in my structure, set 
the offset in tp_weaklistoffset, and initialized it to NULL. It took 
many hours to figure out how this all works, mainly referring to 
funcobject.c for examples. I believe I have this correct now, but I have 
a lot of unexplained crashes that i suspect have to do with the weakref 
list handling.


My third question comes to creating types that are inherited from other 
types. I need the new subtype to add several of its own data fields to 
its own structure. There are no examples of this in the Python source, 
and there is no documentation referring to this. How can my new type 
instances access structure data from its base. My only solution so far 
is to duplicate all the structure members from the parent into the 
child? Then duplicate all the code from the parent into the child. At 
this point my child is actually a standalone type, except it refers to 
the parent in tp_base.


Creating custom types in Python has become very difficult, if you intend 
to support all the recent features of Python. Adding some documentation 
and/or simple examples would go a long way towards a solution. I'm 
wondering if some thought should be put into simplifying the interface. 
Perhaps more macros and generic functions to help manage the new 
features. It shocks me to find nearly every single "PyXXX_FromXXX" 
implements object allocation in entirely independent ways, and none of 
the methods seem very clean to me.

At this point I'm really shooting into the dark. I assume I'll have it 
right when things stop crashing.

If I were to collect a narrowed, specific list of problem topics, would 
the documentation team be interested in looking?





More information about the Python-list mailing list