[issue5370] unpickling vs. __getattr__

Georg Brandl added the comment: Updated docs in r71240. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Pyt

[issue5370] unpickling vs. __getattr__

Gabriel Genellina added the comment: This doc update should warn people about the need to implement __getinitargs__ / __getnewargs__ when the instance relies on some internal invariants that must be preserved, and reiterates the important fact that __init__ / __new__ are NOT normally invoked.

[issue5370] unpickling vs. __getattr__

Gabriel Genellina added the comment: I think that trying to emulate all "getattr" details in the middle of unpickling (but omiting calls to __getattr__) isn't the right thing to do. What if in some cases __getattr__ (or __getattribute__) *does* the right thing, but pickle doesn't call it? Oth

[issue5370] unpickling vs. __getattr__

Mike Meyer added the comment: True. But hat's why it was a QAD hack - all I did was make sure it didn't blow up on the test code, and that it passed the provided unit tests. It really needs to walk the class tree. So something like hasattr(inst.__class__, '__setstate__') is more likely to

[issue5370] unpickling vs. __getattr__

Gabriel Genellina added the comment: Are you sure you uploaded the right patch? I've not tested it, but I don't think this actually fixes the reported bug. __setstate__ is *very* unlikely to be found in the instance's dict, so you end up not calling __setstate__ at all. If no test failed, th

[issue5370] unpickling vs. __getattr__

Mike Meyer added the comment: QAD patch for 2.6 pickle.py to fix this bug. Passes the 2.6 pickle unit tests. -- message_count: 5.0 -> 6.0 Added file: http://bugs.python.org/file13290/pp ___ Python tracker _

[issue5370] unpickling vs. __getattr__

Mike Meyer added the comment: I don't believe in documenting bugs instead of fixing them. If this bug is going to stay in the code, I can either fix my install of Python to have non-broken Pickle modules, or I can fix every third-party libraries objects I use whose authors didn't worry about pic

[issue5370] unpickling vs. __getattr__

Gabriel Genellina added the comment: Perhaps this should be made more clear in the documentation for the pickle module. Probably here: http://docs.python.org/library/pickle.html#the-pickle- protocol Could you come with some enhancements? (Note that it already states that __init__ is not cal

[issue5370] unpickling vs. __getattr__

Mike Meyer added the comment: The args attribute gets created by __init__ and nothing in the class removes it. I don't think it's unreasonable for the class to expect the attribute to not vanish on it. Possibly it should be spelled __args (or declared private :-), but neither of those would make

[issue5370] unpickling vs. __getattr__

Gabriel Genellina added the comment: The __getattr__ method, as written, assumes that an attribute 'args' already exists. That's unsafe - a more robust approach would be: def __getattr__(self, name): if 'attrs' in self.__dict__ and name in self.attrs: return self.attrs[

[issue5370] unpickling vs. __getattr__

New submission from Mike Meyer : The attached short file causes all of python 2.5, 2.6 and 3.0 to drop into infinite recursion trying to unpickle the created object, but the 2.5 version has the cleanest The problem appears to be that the unpickle code (C in 3.0; Python in 2.5 - I assume the other