Embedding Python

Started by
7 comments, last by WarPig 20 years, 4 months ago
Hi I''m using Boost.Python and trying to embedde Python into C++ app. Take a look on this minimalistic code: #include <Python.h> #include <boost/python.hpp> using namespace boost:ython; char const* please_work() { return "Thank God!"; } BOOST_PYTHON_MODULE(testme) { def("please_work", please_work); } int main() { Py_Initialize(); PyRun_SimpleString("import testme\n" "print testme.please_work()\n"); Py_Finalize(); return 0; } Compile & run and I''ve got: ImportError: No module named testme Huh ? Did I forget something ? no more war pigs of the power
no more war pigs of the power
Advertisement
You need to notify python that the testme module is a builtin module.
That is, it doesn't exist as an external script but is part of the binary itself.
(like sys, math... which are compiled into the python interpreter)

To do so, use the PyImport_AppendInittab() function before Py_Initialize().
PyImport_AppendInittab("testme", inittestme);Py_Initialize();PyRun_SimpleString("import testme\n""print testme.please_work()\n");Py_Finalize();  

initfoo is the standard Python initialisation entry point for the extension module named foo .
Boost.Python should have generated it for you.

Checking the return values from those functions may also be helpful.

[ Start Here ! | How To Ask Smart Questions | Recommended C++ Books | C++ FAQ Lite | Function Ptrs | CppTips Archive ]
[ Header Files | File Format Docs | LNK2001 | C++ STL Doc | STLPort | Free C++ IDE | Boost C++ Lib | MSVC6 Lib Fixes ]


[edited by - Fruny on November 13, 2003 12:59:03 PM]
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
First:
Make a DLL project
Second:
Add your codes,and make sure your project name is same with Dll project.

game design
Thanks Fruny, I needed that.

I have another question. Suppose some script uses Simple Generators. Now, this script would be executed from C++ ... is it possible that after yield statement control would be returned to C++ app ? Or there is some other way to stop script execution, save it state, execute C++ code and next continue at resumed line ?
no more war pigs of the power
The best way to know what happens is to try it. But I''d think that if a generator is called by your C++ program then eventually it will have to return control to that program - there''s nothing else it can do. Any state in that generator will be preserved unless you call Py_Finalize, I expect.

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]
quote:Original post by WarPig
I have another question. Suppose some script uses Simple Generators. Now, this script would be executed from C++ ... is it possible that after yield statement control would be returned to C++ app

I found it easier to write my script scheduler in python, and have this scheduler call out to the generator scripts. The scheduler is called once per frame in c++ (through the very-high-level embedding). It is up to the generator scripts to remember to yield execution- if they don''t keep this in mind, the script will block execution.

Sample code:
http://urbanhunting.com/~dustin/katana2/script.cpp
http://urbanhunting.com/~dustin/katana2/internal.py
http://urbanhunting.com/~dustin/katana2/example.py

In my C++ mainloop I simply call Script::update() once per frame.

Dustin
Big THX !!!
no more war pigs of the power
Nice code thedustbustr, but what if I have to load scripts form virtual file system ?
no more war pigs of the power
Virtual filesystems ? Python 2.3 can import scripts directly from zip archives (PEP 273). Is that what you want ? Or do you want something like LUFS-Python ?

[edited by - Fruny on December 16, 2003 2:04:11 PM]
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan

This topic is closed to new replies.

Advertisement