Port the C extension to Python 3? about extensionclass HOT 13 CLOSED

zopefoundation/persistent#46 suggests that porting the extension could be worthwhile (rather than jamming gunk into persistent to work around its lack).

from extensionclass.

Isn't ExtensionClass effectively deprecated given new-style classes (the only kind of classes in Python 3)? Does it make sense to encourage migration away from it?

from extensionclass.

@jamadden Good question. It would be nice if we could get completely rid of ExtensionClass. But I do not know enough the internals. @hannosch What do you think about this?

from extensionclass.

I don't think getting rid of ExtensionClass is feasible in the short term. The __of__ protocol it implements together with Acquisition are used by too much code in Zope.

But I think it is totally fine to only use Python implementations of ExtensionClass and Acquisition and anything that derives from it for Python 3. That way we get PyPy support for free.

Most of the C extensions in Zope were written, because it wasn't possible to write their functionality in Python at the time. But these days descriptors, metaclasses and `getattribute`` from new-style class should make all of them doable in pure Python.

from extensionclass.

@hannosch Thanks for the clarification, closing this issue now.

from extensionclass.

I opened the pull request on persistent, because I thought other users (not only Persistence) could potentially use it to unghost a cPersisten.Persistent object.
It is part of the public C-API so why not having it in python?

Having said this I think that ExtensionClass should be ported.
I see it for performance reasons. The C-Extension of Acquisition and AccessControl depend on ExtensionClass, which are both heavily used in Zope2.

I gave it a try (all the unittests are good) here: master...axiros:master

As you can see it is a quite change, so it would be nice if somebody with more background knowledge of ExtensionClass could review it.

from extensionclass.

@stephan-hof Thanks for that work! I have just merged some cleanups to master (dropping support for Python 2.6 and 3.2, adding support for 3.5, etc.) in #8. Would you be willing to rebase your work against the merged master and submit a pull request from your branch?

from extensionclass.

This was done via #9.

from extensionclass.

I'll have to reopen this. When updating Zope master to the new ExtensionClass 4.2.0 release, we are getting new test failures (on Python 2.7).

I don't see a clear problem and it's not that many. It might be related to classes inheriting from ExtenstionClass.Base and using either @property or ComputedAttribute(). But there's also a couple ending up in AccessControl permission errors which are even more obscore.

from extensionclass.

Will this issue be reopened?

from extensionclass.

I thought I had clicked the "comment and reopen" button - looks like I didn't.

In addition to the above mentioned test failures, it seems the header file is also not updated. There are still references to ->ob_type in it. I only noticed this when copy/pasting that header file into other projects.

from extensionclass.

I played with ZTUtils.tests.testTree.testEncodeDecode as it fails with 4.2.0 and works with 4.1.2 of ExtensionClass. The difference is in Base_getattro.

4.2.0 calls always the descriptor of res if res inherits from ExtensionClass.
See https://github.com/zopefoundation/ExtensionClass/blob/master/src/ExtensionClass/_ExtensionClass.c#L66 till 74

My thinking was to use PyObject_GenericGetAttr for the attribute lookup and compensate the following https://github.com/zopefoundation/ExtensionClass/blob/4.1.2/src/ExtensionClass/_ExtensionClass.c#L155
The code of Base_getattro in 4.12 was a copy&paste of PyObject_GenericGetAttr having the extension at line 155. The extension to PyObject_GenericGetAttr was to ensure that of_get gets also called if the descriptor is found in the dict. Python only calling descriptors on a class level not on attributes inside the instance dict.

My goal was to get rid of the copy&paste of PyObject_GenericGetAttr. However my implementation has a flaw when the attribute is on the class level AND the result of the descriptor is again an ExtensionClass, because now.

• Python calls the descriptor (correctly) and returns the result of it.
• Line 66 in ExtensionClass 4.2.0 checks the result for ExtensionClass (and other minor stuff) and calls the descriptor again. Which is wrong !

I think we have to bring back the copy&paste of PyObject_GenericGetAttr, since it is impossible to know if the result of PyObject_GenericGetAttr came from the instance dict (where it's needed to call the descriptor) or from the class (where python already called the descriptor) :(

from extensionclass.

Once more closed via #11.

from extensionclass.