When declaring a %shared_ptr to a %template type declaration, SWIG requires you to specify the full type in the %shared_ptr statement; otherwise it only provides an opaque SwigPyObject (for example) in the target language. Fully specifying the type in the %shared_ptr statement instead of referring to a typedef'ed name allows correct access to the underlying object.
Credit to Johan Hake for the workaround:
Original message to the list is below, with an attached example.
I am trying to wrap a C++ library which passes around boost::shared_ptr's to STL containers (set, map, etc). It was easy enough to wrap shared_ptr<Object>, and set<shared_ptr<Object> > and make use of those objects and C++ methods from Python, but whenever I try to wrap shared_ptr< set < shared_ptr<Object> > >, the object I get back in Python is just a SwigPyObject that I can't seem to do anything useful with. Google didn't help much.
It seems like I need some sort of combination of %shared_ptr() and %template(), but I can't quite figure out how that would work. Is a shared_ptr to an STL container supported?
I suppose I could embed some CPython code that would convert between the shared_ptr<stl-container> and the Python object, but that just seems ugly and would add lots of runtime/copy overhead.
A sample interface file is attached. I can make and modify Foo and FooSet objects easily enough. However, the pset_copy, pset_deref, and get_pset functions hand me a worthless SwigPyObject in Python. I also can't use add_to_pset or add_to_set inside of Python, since any FooSet objects I make aren't the right type.
Output from swig version 2.0.4 follows.
swig -v -debug-classes -python -c++ -Wall -I../include -o test2_wrap.cpp test2.i
Language subdirectory: python
Starting language-specific parse...