As I introduced (a long time ago) this demand, let me add my grain of salt here.
The use case is pretty simple, and somewhat common when writing manually C extension class: The reason to write extension class is usually performance, or link into an existing library. When doing this manually (instead of using automatic python-wrapping tools like boost, swig,...) you try to wrap the minimum amount of methods/accessors/...to your underlying c/c++ class, and replicate non-critical methods in python. Moreover, extending your class by adding new methods is usually much more easy in Python, especially if it involve complex but not performance-bounded python-data manipulation. Problem is to make those python-implemented methods avaible to instances of your extension class, especially when those instances are returned by the C layer of your extension. The solution we choose was to change the __class__ of each extension type instance to the python derived newclass implementing all those extra-methods.Not too difficult, a simple encapsulation of all methods returning extension-class instances is enough, and can be automated. This solution is quite common I think, it translate something you do for python-class instances, but then you get the __class__ assignment: only for heap types error. The argument about sub-interpreters is a good one, but not really applicable for this use case: we really want to have one extension type (or a hierarchy of it) shared across all interpreter importing the extension, it just happen that instead of being implemented in pure C/C++, the extension is implemented in C/C++ and Python. The fact that the python parts will be seen everywhere is a feature, not a problem: you expect the replacement of C-implemented methods by Python-implemented method to be as transparent as possible. Alternatives would be to use a heap type for our C extensions classes (we need to check what it would imply, but it may be quite painless) or use some form or delegation instead of assigning to __class__. The later is not really painless, AFAIK, in term of coding complexity and possibly performance (extra lookups steps needed). If there are other solutions or if delegation can be made as simple/efficient as the __class__ mechanism, it would be good to know, and it is I think valuable info for many people writing extension classes. Anyway, my personal position on this has not changed in 10y and is in line with Eloi: I think that beeing a heaptype and allowing assigment to the __class__ attribute of instances is indeed quite orthogonal.. .
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
