Re: [Python-ideas] Allow mutable builtin types (optionally)
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.. .
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-o... ). 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@python.org> a écrit :
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-o... ). 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@python.org> a écrit :
participants (2)
-
Greg -
Guido van Rossum