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

[Guido van Rossum]

So the question remains -- why not use a heap type?

On Wed, Jun 27, 2018 at 2:05 AM Greg <gregory.lielens at gmail.com> 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
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180627/f79eb896/attachment.html>