Antoine Pitrou <pit...@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 > fooled? I don't think so. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5180> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
