[Python-3000] A better way to initialize PyTypeObject

[Talin]

Guido van Rossum wrote:

> Nevertheless, I kind of like this, and would like someone to produce a
> patch for this approach. It is my opinion that without working code it
> is too easy to overlook design flaws. Since you are keen to have this
> in 2.6, the solution would have to be backwards compatible with 2.5,
> so the patch wouldn't have to change every type initializer in the
> system -- it would only have to provide the complete machinery and
> convert a few example types to prove it works.

I've started working on a patch, and I have a few questions.

Most of the members of PyTypeObject are function pointers, and can be 
initialized via the method table. Here's a list of the members which aren't:

     PyObject_VAR_HEAD
     const char *tp_name; /* For printing, in format "<module>.<name>" */
     Py_ssize_t tp_basicsize, tp_itemsize; /* For allocation */
     long tp_flags;
     const char *tp_doc; /* Documentation string */
     Py_ssize_t tp_weaklistoffset;
     struct PyMethodDef *tp_methods;
     struct PyMemberDef *tp_members;
     struct PyGetSetDef *tp_getset;
     struct _typeobject *tp_base;
     PyObject *tp_dict;
     Py_ssize_t tp_dictoffset;
     PyObject *tp_bases;
     PyObject *tp_mro; /* method resolution order */
     PyObject *tp_cache;
     PyObject *tp_subclasses;
     PyObject *tp_weaklist;

My question is: Which of these fields need to be initialized by the user?

Let's assume that we are going with the idea that types are created 
dynamically via a function call rather than statically declared. The 
function that creates a type needs to have a set of parameters that fill 
in the various non-method fields of a type.

So each of the values listed above falls into one of three groups: 1) 
values which need to be parameters to the creation function, 2) values 
which can be filled in by the user later, and 3) values which don't need 
to be supplied by the user because they will be filled in automatically 
by the VM.

I can make some guesses as to which fields fall into which group, but 
I'm not sure in all cases. I want to avoid having a single C function 
with a dozen input arguments.

One other question is how to deal with initialization of types with 
multiple base classes. I'm not sure how the API for passing in multiple 
bases ought to look, and how the type object should be constructed in 
the case of more than one base type.

-- Talin