class X(types.ModuleType, str): pass X('name') -> segfault This buggy subclassing goes through typeobject.c's checks because PyModuleObject looks exactly like a user-defined subclass of 'object': it has a PyObject_HEAD followed only by the dict, as specified by tp_dictoffset. A fix would be to forbid any subclassing to move the tp_dictoffset of a non-heap type.
Logged In: YES user_id=4771 The proposed fix is not good enough. If another built-in C type similar to PyModuleObject is defined (say by a C extension module), then it would become possible to subclass both this new type and ModuleType. This might lead to unwanted behavior if e.g. one parent class allows rebinding __dict__ and the other not (and crashes if __dict__ is rebound). This might point to the need for cleaning up typeobject.c's darker corners...
Logged In: YES user_id=6656 > This might point to the need for cleaning up typeobject.c's > darker corners... No kidding. Maybe Samuele, you and I can gang up on Guido at EuroPython (is he sprinting? Perhaps we should ask).
Logged In: YES user_id=4771 The objection to the proposed fix is not valid in light of the bug #1303614, which gives a general way to abuse subclassing to allow the __dict__ of an instance to be assigned to and deleted, even when it should not be allowed. So I wouldn't worry too much about the case I pointed up, because it should be fixed together with #1303614 (though I don't really know how). For now I would be happy with just checking that subclassing a non-heap type doesn't move the dict within the structure. The same remark probably applies to the weakref field. Both cases could be fixed by being more careful in typeobject.c:extra_ivars(): PyModule_Type should be considered to have extra_ivars() when compared to PyBaseObject_Type. This could be achieved by skipping the "t_size -= ..." part if "type" is not a heap type. Indeed, for non-heap types we should not try to consider that an extra dict or weakref slot is not important, because the C code probably accesses this extra slot directly, as in the case of moduleobject.c.
