There are currently two ways to specify a type doc string in PyType_FromSpec; either through the doc field (which is not actually processed), or through Py_tp_doc (which works correctly).

The original concern for adding doc into the TypeSpec was that the slots may only refer to function pointers; as it turns out, putting character pointers in there works fine as well, so I recommend to drop the doc field in TypeSlot.

The patch also fixes some labelling in the xxlimited module.

Looks good.

Thansk for the review. Committed as r88400.

You bring the tp_doc parameter pointer 
into the ownership of the new typeobject?
and tp_doc is assumed to be created by pyObject_malloc?
IMO, if CPython wants to be the owner of the string parameter,
then it should make a copy of that parameter (tp_doc) 
and become owner of that copy.

It's the same as the current tp_doc parameter for static type objects, and essentially like any other doc string in the C API. It's owned by the extension module, which must make sure it lives at least as long as the type object.

Hello, I'm just a app developer which is embedding the python32.dll
and I assumed (and wished) python would simply copy my allocated parameter-string into the type object (( spec->name) is copied too). I looked in the source and see this ownership confirmed:

static void 
type_dealloc(PyTypeObject *type)
.... PyObject_Free((char *)type->tp_doc);

The typeobject owns tp_doc and even requires a special allocation (pyobject_malloc), which is no problem if the type creates its own copy; the hosting app is not connected.

I see. This is an issue independent of the issue discussed here, though, please open a new issue for that. I agree that either tp_dealloc should not release the string, or should make a copy that it can release.