Do you have any ideas on methods for supporting pyglet / ctypes data?
Something that would probably have to occur is the support of binary
data (e.g. jsonpickle will not serialized a File object currently).
> You received this message because you are subscribed to the Google Groups "jsonpickle" group.
> To post to this group, send email to jsonp...@googlegroups.com.
> To unsubscribe from this group, send email to jsonpickle+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/jsonpickle?hl=en.
Hmm that should work. We have another method, too,
which is registering handler objects.
Can you show me an example where __getstate__ and
__setstate__ do not work as expected?
I pushed a fix that makes the decoding work for the
JSON produced when encoding a pyglets.resource.image().
It's in my "refs" branch:
I added warnings on decode to let you know that something went
wrong. We might want to improve this
(maybe have a way to disable warnings?)
Can you please try it out and let me know if it looks good?
I'll need a little more time to write a test case.
I'm looking through the python stdlib to see if there's a
class that we can use that exhibits this same problem
so we can add a test to cover it. If I can't find something
there I might add a conditional test that loads a common
library from /usr/lib64 using ctypes. If anybody has any
suggestions on what would make a good test object please
let me know (criteria: dependency-free and either part
of the python stdlib or a common enough library that it
would exist on both stock OS X and Linux installations).
But, yeah, it'll probably take me a bit longer to write
a good test case. This definitely needs a test.
> So the question here is: is the jsonpickle code intended to encode
> objects such as the above example, that even pickle doesn't support?
> If not, should jsonpickle fail with an explicit error message during
> encode, instead of with a mysterious "list index out of range" error
> during decoding?
We do our best, but there are cases where we cannot restore the
object. Things like database cursors, C extension modules --
that sorta thing.
The idea is that encode() can still be useful in these
situations because the JSON can still be useful to others
even if the object cannot be restored.
What we're doing is warning on decode(). That makes sense to me
since it is in-line with the idea that jsonpickle is not the only
consumer of encode()'s output.