[Python-ideas] Allow mutable builtin types (optionally)

Greg gregory.lielens at gmail.com
Wed Jun 27 05:04:12 EDT 2018

As I introduced (a long time ago) this demand, let me add my grain of salt

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..

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180627/a7374b5c/attachment-0001.html>

More information about the Python-ideas mailing list