This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients alexandre.vassalotti, belopolsky, lemburg, mark.dickinson, pitrou
Date 2010-06-28.23:32:38
SpamBayes Score 0.005408019
Marked as misclassified No
Message-id <1277767961.1.0.370916312034.issue5180@psf.upfronthosting.co.za>
In-reply-to
Content
> My patch attempts to emulate 2.x PyInstance_NewRaw with a call to
> tp_alloc.

This is certainly the wrong thing to do. You could at least try PyBaseObject_Type.tp_new (see object_new() in typeobject.c), but even this is not necessarily right (for example if the class is derived from an extension type defining its own tp_new).

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)

That way you choose the right constructor function, yet don't call the Python-defined __new__ function. That's the only reasonable way of doing it I can imagine. It also follows the following behaviour:

>>> class C(int):
...   def __new__(cls, *a):
...     print "__new__", a
...     return int.__new__(cls, *a)
... 
>>> C(5)
__new__ (5,)
5
>>> s = pickle.dumps(C(5))
__new__ (5,)
>>> x = pickle.loads(s)
>>> x
5

As you can see, int.__new__ has been called on unpickling but not C.__new__ (no print).
History
Date User Action Args
2010-06-28 23:32:41pitrousetrecipients: + pitrou, lemburg, mark.dickinson, belopolsky, alexandre.vassalotti
2010-06-28 23:32:41pitrousetmessageid: <1277767961.1.0.370916312034.issue5180@psf.upfronthosting.co.za>
2010-06-28 23:32:39pitroulinkissue5180 messages
2010-06-28 23:32:39pitroucreate