This page will be a collection point for issues and samples dealing with embedding wxPython in a C++ application, and for writing your own Python extensions that integrate with wxWindows and wxPython. Currently the relevant info is rather scattered, but it should all end up here eventually.
(still to be written)
wxPython and the GIL
One of the things that both extenders and embedders shoudl be aware of is that all wxPython method/function wrappers have a certain way of dealing with the Python Global Interpreter Lock, and that your code should also do the same thing.
The general rule is this:
1. Calls from Python to C++ code should be wrapped in:
tstate = wxPyBeginAllowThreads(); ... wxPyEndAllowThreads(tstate);
The first saves the thread state and releases the GIL. The second restores the tstate and reaquires the GIL. wxPython does this for all calls to wrapped methods and functions, and you probably should for any functions in extension modules you have in your app. At least for any that could either cause an event handler callback or that call other wxPython api functions since they will do #2.
2. C++ code that can invoke Python code should be wrapped in:
wxPyBeginBlockThreads(); ... wxPyEndBlockThreads();
The first restores the tstate that was last used on this thread and aquires the GIL. The second releases the GIL again. This should be done not only for directly invoking Python code but also most manipulations of Python objects from C++ as they can cause a del method to be invoked if an object's reference count to drop to zero.
See the example in wxPython/samples/embedding.