-
Notifications
You must be signed in to change notification settings - Fork 57
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
Support __asdf__
interface?
#112
Comments
I had initially considered this, but the shortcoming is that it's only one-way -- you can only use this to store a custom object in ASDF. So you ultimately to have something "off the side" (i.e. not on objects) that can be used to unserialize the objects. This is documented here: http://pyasdf.readthedocs.org/en/latest/pyasdf/extensions.html While there's probably some room for improvement, I think it's superior to using a special member because it wraps the serialization/deserialization in a single class. |
Ok, sounds good! |
I think there's more that goes into storing arbitrary objects in ASDF too. For example you need support in the schema and the like. That could be declared in an object too, but I think in practice Mike's approach is better. |
The other important point I forgot to mention is that doing things "off to the side" like this lets us handle objects we don't control, such as Numpy arrays. (i.e. we can support them in ASDF without submitting patches to Numpy). |
add powered by astropy badge
While playing around with trying to store Astropy objects in ASDF (e.g. astropy/astropy#3733) I was wondering how we might best make it easy for developers to make their kinds of objects storable in ASDF. One option would be to check if objects have a
__asdf__
method that if called will return a valid ASDF structure that can be included in a file? (with all the correct meta-data).The text was updated successfully, but these errors were encountered: