-
-
Notifications
You must be signed in to change notification settings - Fork 180
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
pickle class instances whose class definitions have changed #5
Comments
A very similar situation at sympy/sympy#2538. I can't pickle |
With the fix in Issue #12, this issue should also be working in general -- however, one might run into issues if there things defined out of scope that have changed... but, in general it works as below for instances as well as class definitions themselves.
|
My one still doesn't work. The issue there is not that the class has changed, but that it is created dynamically in |
@asmeurer: can you send me a minimal example? The reason my above example works is that I now serialize the class definitions. Your class definitions haven't changed, but something is used to dynamically generate the instances with |
I tried copying over the relevant logic, but now I get what looks like a bug in dill class _sentinel:
pass
class Test:
def __new__(cls, name):
if name == _sentinel:
obj = object.__new__(cls)
else:
obj = type(name.capitalize() + cls.__name__, (cls,),
{})(_sentinel)
obj.name = name
return obj
import dill
t = Test("Aaron")
dill.dumps(t) Traceback (most recent call last):
File "test.py", line 17, in <module>
dill.dumps(t)
File "/Users/aaronmeurer/anaconda3/envs/dill-dev/lib/python3.3/site-packages/dill/dill.py", line 121, in dumps
dump(obj, file, protocol)
File "/Users/aaronmeurer/anaconda3/envs/dill-dev/lib/python3.3/site-packages/dill/dill.py", line 115, in dump
pik.dump(obj)
File "/Users/aaronmeurer/anaconda3/envs/dill-dev/lib/python3.3/pickle.py", line 235, in dump
self.save(obj)
File "/Users/aaronmeurer/anaconda3/envs/dill-dev/lib/python3.3/pickle.py", line 342, in save
self.save_reduce(obj=obj, *rv)
File "/Users/aaronmeurer/anaconda3/envs/dill-dev/lib/python3.3/pickle.py", line 407, in save_reduce
save(cls)
File "/Users/aaronmeurer/anaconda3/envs/dill-dev/lib/python3.3/pickle.py", line 297, in save
f(self, obj) # Call unbound method with explicit self
File "/Users/aaronmeurer/anaconda3/envs/dill-dev/lib/python3.3/site-packages/dill/dill.py", line 702, in save_type
_dict = _dict_from_dictproxy(obj.__dict__)
File "/Users/aaronmeurer/anaconda3/envs/dill-dev/lib/python3.3/site-packages/dill/dill.py", line 379, in _dict_from_dictproxy
_dict.pop('__dict__')
KeyError: '__dict__' |
Would it make a difference if I removed the part where I set |
Hmmm... the This should probably be a new ticket. I've got to catch a plane, but will dig into this further... as this is a bug I just added for 3.x. |
I guess, but the SymPy code raises PickleError. |
@asmeurer: I just updated to get past the KeyError above. Now your test case pickles, but doesn't unpickle. I believe I should be able to get around this with a little more thought.
|
Let's move this to it's own issue -- #13. |
It seems it still can't pickle the actual object I am interested in in my SymPy branch, though. I get |
Right, so one of the things that python does that's a bit of a 'mistake' is that it associates a function or instance created in a factory pattern (like a curry) with the top level namespace where it was created and not the associated place in the namespace where the code actually lives. It's a common problem for pickling and some other similar things... and the root of a number of objects that fail to serialize with dill. So, I am looking into how to solve that problem... and it sounds like it could be related to the issue you are having. Creating the instance in another file shouldn't matter. Module structure shouldn't matter too much, and an import can often make it easier as opposed to a reference from inner to outer scope within the same file. Encapsulation is the key to making pickling easier. The less you rely on python's namespace management magic, the easier you'll have a time in pickling something. For me, the sympy code would be a back-burner item... but I'm happy to look into it when I get some free space (in ~2-3 weeks) if it's not cleared up by then. |
No problem. It's not high priority for me at the moment. For now, that code just lives in a pull request, and it probably will for some time actually. |
This is an interesting use case, detailed on stackoverflow.
The text was updated successfully, but these errors were encountered: