Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Find a way to persist C extension types #227

Open
adrinjalali opened this issue Nov 30, 2022 · 2 comments
Open

Find a way to persist C extension types #227

adrinjalali opened this issue Nov 30, 2022 · 2 comments
Labels
persistence Secure persistence feature

Comments

@adrinjalali
Copy link
Member

The way pickle persists C extension types (including objects created by cython) is to rely on __reduce__ and __reduce_ex__.

We should find a protocol that third party packages can implement, so that we could avoid relying on __reduce__.

One issue is that we can't call __new__ on C extension types generated by Cython. Cython would raise if the type tries to implement this special method. However, one can implement __cinit__ in cython.

We can certainly require those objects to implement __getstate__ and __setstate__. The remaining issue is the constructor.

Right now we call __new__ for all other objects, but we can't do that here. The question is, should we then call Object() instead? Or should we find a way to have something which acts as a low level and light constructor.

Some links:

@adrinjalali adrinjalali added the persistence Secure persistence feature label Nov 30, 2022
@BenjaminBossan
Copy link
Collaborator

Could you elaborate what C extension types exist that we should support in skops?

The question is, should we then call Object() instead?

IIUC, that would require that all of the class's arguments have default values. Can we expect that?

Or should we find a way to have something which acts as a low level and light constructor.

Could you please give a quick example of what that would look like?

@adrinjalali
Copy link
Member Author

Could you elaborate what C extension types exist that we should support in skops?

We already support the ones from sklearn, but if we want things to work easily for the third party estimators, then we'd need to have a way for it to work w/o us having to hard-code what they are in skops. For instance, if there are any from XGB or lightgbm or any other complied third party library.

IIUC, that would require that all of the class's arguments have default values. Can we expect that?

My bad. I'm suggesting to use __new__ whenever available, and Object() otherwise. This would mean no python object would be constructed using its __init__ since they all have __new__, and only call Object() for other types, such as C extensions.

Could you please give a quick example of what that would look like?

Being able to call __cinit__ from python would be an example.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
persistence Secure persistence feature
Projects
None yet
Development

No branches or pull requests

2 participants