It would be good if PyType_Ready() will check that base class of static type is static.

By static, you mean not a heap type?

Yup.

> By static, you mean not a heap type?

Yes. Sorry for bad wording.

Here is a patch.

Could anyone please make a review?

Ping.

New changeset c087ac6fc171 by Serhiy Storchaka in branch '2.7':
Issue #22079: PyType_Ready() now checks that statically allocated type has
https://hg.python.org/cpython/rev/c087ac6fc171

New changeset 747855f29b9d by Serhiy Storchaka in branch '3.4':
Issue #22079: PyType_Ready() now checks that statically allocated type has
https://hg.python.org/cpython/rev/747855f29b9d

New changeset eb26255e11f1 by Serhiy Storchaka in branch 'default':
Issue #22079: PyType_Ready() now checks that statically allocated type has
https://hg.python.org/cpython/rev/eb26255e11f1

reopening, this breaks some stuff in several places ...

https://bugs.launchpad.net/ubuntu/+source/terminator/+bug/1426294

This restriction was added because bad thing could happen when statically allocated class inherits dynamically allocated class. I don't remember the number of the issue where such example was exposed, may be Alex remember it.

Likely pygobject creates classes in not safe manner. It would be more correct to create pygobject classes with PyType_FromSpec(), but current code worked for it for years. May be it is not so easy to change pygobject. So may be we should revert changes in 2.7 or convert the error to the deprecation warning.

Is there similar issue with 3.4? There may be difference due to the difference of the lifetime of types in 2.x and 3.x.

New changeset aa79a04e9bf5 by Serhiy Storchaka in branch '2.7':
Issue #22079: Py3k warning now is issued in  PyType_Ready() instead of
https://hg.python.org/cpython/rev/aa79a04e9bf5

New changeset 57a457ea84e4 by Serhiy Storchaka in branch '3.4':
Issue #22079: Deprecation warning now is issued in  PyType_Ready() instead of
https://hg.python.org/cpython/rev/57a457ea84e4

I think we can start from index 1 instead of 0.

Can you please explain?

In the mro list I think the first is always the type itself which has already been checked to be a statically allocated type if we can touch the loop. Starting from 0 checks it twice and it's not a base either.

BTW, I don't receive an email from the tracker. :(

__bases__ != mro()

Of course, I know it. But doesn't the local variable `bases` refer to mro[1]?

[1] https://hg.python.org/cpython/file/tip/Objects/typeobject.c#l4900

Good point! tp_bases should be iterated instead of tp_mro in this check.

I thought that too at first. But if we use __bases__, can we still guarantee that 'all bases of statically allocated type should be statically allocated'? How about its grand bases? Is it possible that a statically allocated type inherit a dynamic type but does not go through PyType_Ready and then be inherited?

This is interesting question. It looks that base classes (as well as mro classes) may not go through PyType_Ready. There is no even a check that mro() returns only ancestor classes and contains the initial class itself.

Oh yes. The mro list can be customized so we can not even guarantee the type appears at index 0 and object at index n-1. It seems we should still keep what it is now, iterating the whole mro list.

Sorry that my previous comments seem to be noise. But maybe we can add one comment to clarify that iterating the whole list is needed.