So the question remains -- why not use a heap type? On Wed, Jun 27, 2018 at 2:05 AM Greg <[email protected]> wrote:
> 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 > [email protected] > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
