[issue5180] 3.1 cannot unpickle 2.7-created pickle
report at bugs.python.org
Tue Jun 29 10:36:49 CEST 2010
Antoine Pitrou <pitrou at free.fr> added the comment:
> Well, this is not so obviously wrong as you make it sound. If you
> look closer at object_new(), you will see that in sane situations it
> reduces to type->tp_alloc(type, 0) call.
Today, yes. But tomorrow it may entail additional operations.
> If such sanity check is necessary, I would rather check the flag
> explicitly in _pickle.c rather than having to generate dummy args and
> kwds to satisfy tp_new signature.
I find it better to "generate dummy args and kwds to satisfy tp_new
signature". I see no point in a partial inlining of an internal function
when we could call it instead.
> > So, IMO, the right thing to do would be to choose the first base
> > type that isn't a Python-defined class and use its tp_new:
> > staticbase = subtype;
> > while (staticbase && (staticbase->tp_flags & Py_TPFLAGS_HEAPTYPE))
> > staticbase = staticbase->tp_base;
> > (these two lines are from tp_new_wrapper() in typeobject.c)
> This looks like overengineering to me. I think 3.x should simply
> refuse to unpickle old style class instances into anything that is not
> subclassed in python directly from object.
Right, but it would lead to almost the same code... Since you have to
find the first non-Python base type and check that it is "object".
> It would be helpful at this point if you could provide a test case
> where tp_alloc logic does not work.
I'll try to find one.
> PPS: What is you opinion on the pickle.py trick of monkey patching
> __class__ on an instance of an empty class? Do you think this can be
I don't think so.
Python tracker <report at bugs.python.org>
More information about the Python-bugs-list