[Code, Scripting] Embedding Python

I have no problem with this article after reading through it. I would, however, like to try running through it with a compiler (MinGW) to see if I can work through the examples (plus I've never used Python before).

Looks good from a Python user's point of view. No complaints here.

I followed your article through with MinGW and Code::Blocks. I was able to use your appendix notes to build boost::python into my application, so you may want to mention that the instructions are applicable to that particular IDE/Compiler combo too.

The only thing that confused me slightly was the borrowed references. As I understand, you're just grabbing the reference to an object from Python and using it - is there any chance that something could happen within Python that causes it to perform a GC and make that reference invalid?

Other than that, it was easily for me to follow. Looking forward to part 2.

Looks good to me.

The indications that MSVC will try to link to the debug version of the interpreter and thus fail should be made more proeminent (like a box, sidebar or something, if article formatting supports that). I fear that otherwise, people will try to compile the code, fail (debug mode is the default in MSVC, isn't it?) and not bother reading further.

Maybe you could add links to the Python C API reference for each function being used?

Quote:

Original post by evolutional The only thing that confused me slightly was the borrowed references. As I understand, you're just grabbing the reference to an object from Python and using it - is there any chance that something could happen within Python that causes it to perform a GC and make that reference invalid?

You have a "borrowed" reference when the API gives you a reference without incrementing its reference count. That means that the reference is only valid for as long as the object still exists on the Python side. Yes, you could execute code that would lead to the object being GCed. If you want to keep the object alive even though all the references are gone within the interpreter, it is up to you to increment the reference count.

Quote:

Original post by Fruny You have a "borrowed" reference when the API gives you a reference without incrementing its reference count. That means that the reference is only valid for as long as the object still exists on the Python side. Yes, you could execute code that would lead to the object being GCed. If you want to keep the object alive even though all the references are gone within the interpreter, it is up to you to increment the reference count.

That's what I thought - thanks! It might be worth putting that in as a note somewhere in the article.

Ok, editted version here.

Quote:

Original post by Fruny The indications that MSVC will try to link to the debug version of the interpreter and thus fail should be made more proeminent (like a box, sidebar or something, if article formatting supports that). I fear that otherwise, people will try to compile the code, fail (debug mode is the default in MSVC, isn't it?) and not bother reading further.

I've tried to make the text a little more prominent, but I'm not sure how to get a sidebar with our article formatting.

Quote:

Maybe you could add links to the Python C API reference for each function being used?

I'd feel better about that if the Python C API documentation was a little better. :P

Quote:

Original post by evolutional The only thing that confused me slightly was the borrowed references. As I understand, you're just grabbing the reference to an object from Python and using it - is there any chance that something could happen within Python that causes it to perform a GC and make that reference invalid?

The borrowed references should be a little better explained now.

Looks good to me.

Ok, formatted versions (single and multi-page) here. Fortunately, there's no code archive for me to forget to include this time.

*cough* bump

I don't want to make much more additional work on this, but is it possible to check whether this code works with the forthcoming Python 2.5, which is probably going to be out any week now? As the Scripting Languages forum moderator not only would I like to see this article, but I have a vested interest in this article remaining relevant for quite a while. :)

The code and instructions seem to work fine with Python 2.5 alpha 2 with Boost 1.33.1, which indicates that it should work the 2.5 stable when it comes out. If it doesn't work with earlier versions of Boost, then I don't feel bad at all telling them to upgrade if they want to work with the latest version of Python.