   [Code, Scripting] Embedding Python
Link
  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 evolutionalThe 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 FrunyYou 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 FrunyThe 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. :PQuote:Original post by evolutionalThe 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   