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

[Greg]

Mostly historical reasons I guess, we started with static types because
most class extension examples were using it, and it worked for all we did
at the time (including the __class__ assign trick). We then got hit by the
change, and solved the issue by patching python.
Now keeping our own patched CPython is still perfectly viable, but there
are disadvantages to not using the off-the-self interpreter: it prevent
interacting with other proprietary libs within a single interpreter. So
that would be plan C (BTW having a common interpreter is a necessary
condition, but far from enough...)

Plan A was to push the idea that extension type behavior could be more
tunable: ATM you choose between static and heap type, and it comes with a
bunch of other non obvious differences, whose combination is not
necessarily the best for your use case or preferences (see for example
http://grokbase.com/t/python/python-dev/097twacntz/py-tpflags-heaptype-too-overloaded
).
I still think it's s good idea to allow for more tunable behavior, and
certainly not use heap type as a marker for things not obviously related,
but as it did not gather traction 10y ago, nor this time either, so I will
not push for plan A. Time has teached me it is better to wait for the
proposal come back from another source, than invest too much time in it if
support, or at least discussion is not strong from the start. It will
probably come back and pass later, in a form or another ( PEP225/465 ;-p )

Plan B is to see how much additional work it will be to use heap type, and
if we do not suffer from it's other properties. If we end up requiring
another patch, bye bye plan B and back to the original patch.


Le mer. 27 juin 2018 à 19:46, Guido van Rossum <guido at python.org> a écrit :

> 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/20180628/7cb2059c/attachment.html>