Problems embedding python 2.6 in C++

[Gabriel Genellina]

En Mon, 01 Feb 2010 18:21:56 -0300, Paul <gobladoome at gmail.com> escribió:

> I'm extending some old Visual Studio 6 code to add embedded python
> scripting. It works fine most of the time but some python function calls  
> do
> not work as expected.
>
> The C++ code is a multithreaded MFC application. I was assuming that it  
> was
> GIL issues but I have tried using the manual locking (PyEval_SaveThread &
> PyEval_RestoreThread) and what seems to be the current method
> (PyGILState_Ensure & PyGILState_Release)
>
> Here's the error I'm getting:
>
>  Traceback (most recent call last):
>   File "...scripts\receipt_parser.py", line 296, in
> get_giftcard_purchase_value
>     details = extract_transaction_details_section(test)
>   File "...scripts\receipt_parser.py", line 204, in
> extract_transaction_details_section
>     for line in base_details:
> TypeError: expected string or Unicode object, NoneType found
>
> base_details is a list of strings (I can just define it like
> 'base_details=["1","2","3"...]' on the line previous) and the code runs  
> fine
> when run from standard interpreter. Many other function calls work fine  
> from
> the embedded app.
> I create and then Py_DECREF the function parameters and the return value
> after each function call. The module import is created at C++ object
> constructor and then Py_DECREF'd in the desctuctor

Usually, errors in reference count handling prevent objects from being  
destroyed (a memory leak) or generate a GPF when accessing an  
now-inexistent object. In principle I'd look elsewhere.

> Anyone else had issues of this kind?

Hard to tell without more info. base_details is built in C++ code? Is it  
actually a list, or a subclass defined by you?
A common error is to forget to check *every* API function call for errors,  
so errors get unnoticed for a while but are reported on the next check,  
which may happen in an entirely unrelated function.

> My next try will be to use
> sub-interpreters per thread.

I would not do that - I'd try to *simplify* the code to test, not make it  
more complicated.
Does it work in a single-threaded application?

-- 
Gabriel Genellina