[issue3453] PyType_Ready doesn't ensure that all bases are ready

2014-10-29 Thread Antoine Pitrou
Changes by Antoine Pitrou pit...@free.fr: -- versions: +Python 3.5 -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3453 ___ ___

[issue3453] PyType_Ready doesn't ensure that all bases are ready

2014-10-28 Thread Eldar Abusalimov
Eldar Abusalimov added the comment: It is possible to get a partially initialized class from inside a custom mro(). And extending such type results in passing NULL to PySequence_List inside mro_implementation, which in turn leads to PyErr_BadInternalCall. #22735 has a test reproducing it

[issue3453] PyType_Ready doesn't ensure that all bases are ready

2013-07-24 Thread Ronald Oussoren
Ronald Oussoren added the comment: I don't know if multiple inheritance is explicitly supported at the C level, but it is possible to create an extension type with multiple base classes in tp_bases. -- nosy: +ronaldoussoren ___ Python tracker

[issue3453] PyType_Ready doesn't ensure that all bases are ready

2010-06-10 Thread Alexander Belopolsky
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: My knowledge may be out of date, but I thought multiple inheritance was only supported at the python level. If this is still the case, then no initialization check is needed. (You cannot get an uninitialized type at

[issue3453] PyType_Ready doesn't ensure that all bases are ready

2008-08-19 Thread Roger Upole
Roger Upole [EMAIL PROTECTED] added the comment: This doesn't address the discrepancy between tp_base and tp_bases. If multiple bases are used, it's no longer 'good practice', it's an absolute requirement. IMO, it should call PyType_Ready for all bases, or none of them. Since the code assumes

[issue3453] PyType_Ready doesn't ensure that all bases are ready

2008-07-29 Thread Amaury Forgeot d'Arc
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: PyType_Ready is called for each class in tp_bases. This is done in typeobject.c::best_base() Isn't it the case in your program? -- nosy: +amaury.forgeotdarc ___ Python tracker [EMAIL

[issue3453] PyType_Ready doesn't ensure that all bases are ready

2008-07-29 Thread Amaury Forgeot d'Arc
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Forget my last remark: it applies to heap types (created with type_new()) and not to static types. However, it seems that a non-ready class in tp_bases can happen only when an extension type inherits from another extension type. It is

[issue3453] PyType_Ready doesn't ensure that all bases are ready

2008-07-28 Thread Roger Upole
Roger Upole [EMAIL PROTECTED] added the comment: If that were the case, it wouldn't need to call PyType_Ready for tp_base either. From stepping thru the code, there are several places in the interpreter core that PyType_Ready is called for types whose tp_base has not been initialized yet.

[issue3453] PyType_Ready doesn't ensure that all bases are ready

2008-07-27 Thread Roger Upole
New submission from Roger Upole [EMAIL PROTECTED]: If a type's tp_base has not been initialized yet, PyType_Ready calls itself for tp_base. However, it doesn't do the same for members of tp_bases. The inheritance determinations assume that all bases are ready, in particular that tp_mro is

[issue3453] PyType_Ready doesn't ensure that all bases are ready

2008-07-27 Thread Benjamin Peterson
Benjamin Peterson [EMAIL PROTECTED] added the comment: I believe that's because the bases are supposed to be ready at the time a subclass is created. -- nosy: +benjamin.peterson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3453