> 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.