<div dir="ltr"><div>As I introduced (a long time ago) this demand, let me add my grain of salt here.</div><div><br></div><div>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. <br></div><div>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.</div><div> 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.</div><div>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. <br></div><div><br></div><div>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.<br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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)</div><div>or use some form or delegation instead of assigning to __class__.</div><div>The later is not really painless, AFAIK, in term of coding complexity and possibly performance (extra lookups steps needed).</div><div><br></div><div>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.<br></div><div>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..<br></div><div><br></div><div><br></div><div><br></div><div><code>.</code></div><div><code><br></code></div><div><code><br></code></div><div><code><br></code></div><div><code><br></code></div><div><code><br></code></div><code><span class="gmail-pln"></span></code> <br></div>