PyObject_New

[Jeremy Moles]

Hey guys, sorry to ask another question of this nature, but I can't find
the answer or a single example of it anywhere. I'm sure it's been asked
before, but my google-fu isn't strong enough to find anything.

I have the following:

struct MyType {
PyObject_HEAD
...
};

PyTypeObject PyType_MyType = { ... }

Now, elsewhere in the code I want to create an instance of this custom
type in C/C++ (rather than in the Python interpreter, where this all
seems to happen magically) and return it from a method. What I'm trying
now is the following:

PyObject* obj = _PyObject_New(& PyType_MyType);
obj = PyObject_Init(o bj, &PyType_MyType) ;

...

return obj;

When "obj" gets back to the interpreter, Python sees it (or rather, it's
__repr__) in accordance with what it "should" be. However, any attempt
to USE the object results in a segfault. I feel my problem is simply
that I'm not allocating "obj" correctly in the C++ function.

If anyone has any advice, I would really appreciate it.

[Martin v. Löwis]

Re: PyObject_New

Jeremy Moles wrote:[color=blue]
> PyObject* obj = _PyObject_New(& PyType_MyType);
> obj = PyObject_Init(o bj, &PyType_MyType) ;
>
> ...
>
> return obj;[/color]

The call to PyObject_Init is redundant: _PyObject_New
is malloc+init. However, this shouldn't cause any crashes (except in the
debug build). PyObject_Init is documented as

Initialize a newly-allocated object op with its type and initial
reference. Returns the initialized object. If type indicates that the
object participates in the cyclic garbage detector, it is added to the
detector's set of observed objects. Other fields of the object are not
affected.

[I don't know where the mentioning of GC comes from - it appears to be
incorrect]
[color=blue]
> When "obj" gets back to the interpreter, Python sees it (or rather, it's
> __repr__) in accordance with what it "should" be. However, any attempt
> to USE the object results in a segfault. I feel my problem is simply
> that I'm not allocating "obj" correctly in the C++ function.[/color]

It doesn't crash because of the allocation - this code is correct.
However, it is also incomplete: none of the state of the new object
gets initialized in the fragment you are showing. So it likely crashes
because the members of the object are stray pointers or some such,
and accessing them causes a crash.

Regards,
Martin

[Jeremy Moles]

Re: PyObject_New

I just noticed this response right as I sent my other message. For some
reason my news reader didn't thread it, so it was all by itself...
Please disregard the rant concerning creation of objects in C. :)

/me hugs Martin
/me ducks and hides!

On Fri, 2005-10-07 at 09:57 +0200, "Martin v. Löwis" wrote:[color=blue]
> Jeremy Moles wrote:[color=green]
> > PyObject* obj = _PyObject_New(& PyType_MyType);
> > obj = PyObject_Init(o bj, &PyType_MyType) ;
> >
> > ...
> >
> > return obj;[/color]
>
> The call to PyObject_Init is redundant: _PyObject_New
> is malloc+init. However, this shouldn't cause any crashes (except in the
> debug build). PyObject_Init is documented as
>
> Initialize a newly-allocated object op with its type and initial
> reference. Returns the initialized object. If type indicates that the
> object participates in the cyclic garbage detector, it is added to the
> detector's set of observed objects. Other fields of the object are not
> affected.
>
> [I don't know where the mentioning of GC comes from - it appears to be
> incorrect]
>[color=green]
> > When "obj" gets back to the interpreter, Python sees it (or rather, it's
> > __repr__) in accordance with what it "should" be. However, any attempt
> > to USE the object results in a segfault. I feel my problem is simply
> > that I'm not allocating "obj" correctly in the C++ function.[/color]
>
> It doesn't crash because of the allocation - this code is correct.
> However, it is also incomplete: none of the state of the new object
> gets initialized in the fragment you are showing. So it likely crashes
> because the members of the object are stray pointers or some such,
> and accessing them causes a crash.
>
> Regards,
> Martin[/color]