-
-
Notifications
You must be signed in to change notification settings - Fork 181
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
enable byref=False for classes defined in modules #128
Comments
Related to #123, somewhat, I think. Also note that using |
Has anything happened with this? I'm in a context where I need to serialize classes for passing out over a RPC layer, and the fact that classes seem to be serialized by reference is a problem. |
@matsjoyce: I went back and looked at the timings, and I'd be happy to see #47 (and related) resurrected, and have them go in at least in a |
Has there been any progress on this? |
No. The way dill currently handles objects is a mix of reference and complete serialization (modifiable to some extent with flags). I think to fully cover cases like this requires a bit of a redesign of dill as if we continue adding flags we're going to end up with a bit of a mess. Ideally we'd write several serialization functions for each type (for complete and by reference serialization, also see all the different ways we serialize files) and have some sort of general way to switch between modes. However doing this in dill is difficult due to all the compatibility code with various old python versions and the fact that people don't always like breaking API changes. I was considering writing a new serialization module that did this but since I don't have a need for it at the moment not much has been done. Anyway, in the short term, if you need to adjust the behaviour of dill you can override the pickler for a particular type quite easily using |
I don't want to be pushy, but has there been any progress until now? Or is there a way I can make it work with flags so I can send my object from a class which I imported from a module via dill? |
@make-ing: It's the same answer as less than a month ago. If you'd like the flags to work for this particular case, you either need to make some small hacks to turn on |
@matsjoyce: We don't store classes defined in |
Any update on this feature? My use case is I have an parent class and a child class. When I dill the child class and then undill it in location where the parent doesn't exist, I get an error trying to call methods of the parent class because only references to those methods were dilled, not the methods themselves. |
Is there any other way around to save the class definition along with the pickled object? |
See: http://stackoverflow.com/questions/32363312/why-dill-dumps-external-classes-by-reference-no-matter-what
We also define
Foo
dynamically, for comparison.So when Foo is defined in
__main__
,byref
is respected.However, when the class is defined in a module,
byref
is not respected.Note, that I wouldn't use the recurse option in this case, as
Foo.y
will likely infinitely recurse. That's also something that I believe there's current ticket for, but if there isn't, there should be.Let's dig a little deeper… what if we modify the instance…
No biggie, it pulls in the dynamically added code. However, we'd probably like to modify
Foo
and not the instance.Ok, that's fine, but what about the
Foo
in our external module?Hmmm… not good. So the above is probably a pretty compelling use case to change the behavior
dill
exhibits for classes defined in modules -- or at least enable one of the settings to provide better behavior.The text was updated successfully, but these errors were encountered: