When a Python type is defined in a C extension module as a static type, its documentation can be a NULL string (NULL pointer). But PyType_FromSpec() does crash if tp_doc is NULL, since this change:

commit 032400b2d83ba1c2e4ee1cd33f51e9a598b2cf6c
Author: Georg Brandl <georg@python.org>
Date:   Sat Feb 19 21:47:02 2011 +0000

    #11249: in PyType_FromSpec, copy tp_doc slot since it usually will point to a static string literal which should not be deallocated together with the type.

(...)
diff --git a/Objects/typeobject.c b/Objects/typeobject.c
index e9c7591b81..b1fe44ebe4 100644
--- a/Objects/typeobject.c
+++ b/Objects/typeobject.c
@@ -2347,6 +2347,17 @@ PyObject* PyType_FromSpec(PyType_Spec *spec)
            goto fail;
        }
        *(void**)(res_start + slotoffsets[slot->slot]) = slot->pfunc;
+
+        /* need to make a copy of the docstring slot, which usually
+           points to a static string literal */
+        if (slot->slot == Py_tp_doc) {
+            ssize_t len = strlen(slot->pfunc)+1;
+            char *tp_doc = PyObject_MALLOC(len);
+            if (tp_doc == NULL)
+               goto fail;
+            memcpy(tp_doc, slot->pfunc, len);
+            res->ht_type.tp_doc = tp_doc;
+        }
     }
 
     return (PyObject*)res;


I propose to accept tp_doc=NULL in PyType_FromSpec(), as we do in static types.

I noticed this difference while reviewing PR 22220 which convert _lsprof extension static types to heap types.

I will take a look in this weekend :)

The PyType_Slot documentation says that the pointer may not be NULL: https://docs.python.org/3/c-api/type.html?highlight=pytype_fromspec#c.PyType_Slot.PyType_Slot.pfunc

If you change this, why do it only for tp_doc, but for all the slots? NULL should *always* mean that the slot is set to NULL instead of inherited. (Except maybe in cases where this is dangerous; then it should result in an error?)
See: https://bugs.python.org/issue26979

If you want to only change this for tp_doc, please also update the PyType_Slot documentation to cover the exception.

> If you change this, why do it only for tp_doc, but for all the slots? NULL should *always* mean that the slot is set to NULL instead of inherited. (Except maybe in cases where this is dangerous; then it should result in an error?

IMO, it's a proper user case.
From bpo-26978: "I'll also try making an explicit `{Py_tp_dealloc, NULL}` override the inherited value, as per Serhiy's suggestion."
Petr, do you have a PR about it?

> If you want to only change this for tp_doc, please also update the PyType_Slot documentation to cover the exception.

Copy that, I will update it soon.

New changeset 88c2cfd9ffbcfc43fd1364f2984852a819547d43 by Hai Shi in branch 'master':
bpo-41832: PyType_FromModuleAndSpec() now accepts NULL tp_doc (GH-23123)
https://github.com/python/cpython/commit/88c2cfd9ffbcfc43fd1364f2984852a819547d43

Thanks Hai Shi.

Thank you all:)

The PR entirely removed the note that a slot's value "May not be NULL".
In fact, only tp_doc may be NULL. AFAIK, the restriction is still there for other slots.
Can that note be added back?

> The PR entirely removed the note that a slot's value "May not be NULL".
> In fact, only tp_doc may be NULL. AFAIK, the restriction is still there > for other slots.
> Can that note be added back?

`May not be NULL` means everthing is possible, so I decided removed it:(
Before, I updated an old commit in PR23123 to describe this fact in https://github.com/python/cpython/pull/23123/commits/cca7bc7edf11a7d212ae70dcff6f10cf96fab470.

> `May not be NULL` means everthing is possible

No, it does not. It only means a slot's value may not be NULL, which is an important difference between slots and entries in the PyTypeObject structure.

It's OK that it's mentioned elsewhere, but can we please put it back in the docs of PyType_Slot?

New changeset 2b39da49974bda523c5c1a8777bbe30dbafdcd12 by Hai Shi in branch 'master':
bpo-41832: Restore note about NULL in PyType_Slot.pfunc (GH-23243)
https://github.com/python/cpython/commit/2b39da49974bda523c5c1a8777bbe30dbafdcd12

Hi, petr. If there is no other doubt about this bpo, I suggest close this bpo.

Sorry Petr, I didn't notice that the note was fully removed in the first change. Thanks for restoring the note!