homepage

As with every type, that has been created and initialized, HeapTypes created form PyType_FromSpecWithBases() have to pass through PyType_Ready(). Here the function inherit_special might be called, which, among other things, does the following:
....
3892 if (base != &PyBaseObject_Type || 
3893 (type->tp_flags & Py_TPFLAGS_HEAPTYPE)) {
3894 if (type->tp_new == NULL)
3895 type->tp_new = base->tp_new;
3896 }
....
The code does not know of Heaptypes that have been created from extension-types by the PEP 384 refactorings. This includes extension-types that do not specify a tp_new method but instead have seperate factory methods, that are only used within the extension module. inherit_special() might consequently assign inappropriate new-methods to these type objects.
To circumvent this issue, I propose to enhance PyType_FromSpecWithBases in the following way: If no tp_new has been specified, we assign the newly defined PySpec_New() method to tp_new which simply denies the user to create an instance of this type. This also prohibits inherit_special to falsely inherit inappropriate new-methods.

Can you give an example of the situation that you described? Perhaps you encountered it while refactoring some particular extension module. Which?
In your patch new code is commented out.
PySpec_New() is not a good name. It should be something like PyObject_FailingNew().

Here is revised version of the patch. 
Martin von Löwis and I had discovered a way to reproduce problems with refactored modules, that
occur without this patch. This is was several months ago, however I will try to give you a code sample! :-)

Robin, do you remember which extension types were affected by this issue?

Affected modules were tkinter and curses (see issue23815). This was fixed by explicit nullifying tp_new after calling PyType_FromSpec(). Issue26979 was open for documenting this danger effect.

Converting static types to heap ones is just one of the reasons to use PyType_FromSpec*. Another ones are writing such classes from scratch, and converting pure-Python classes to C. I don't think PyObject_FailingNew is a good default for either of those.
I think Sehriy's solution in bpo-26979 is better: document this, and allow setting a slot to NULL explicitly.