By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,110 Members | 990 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,110 IT Pros & Developers. It's quick & easy.

Embedding Python question.

P: n/a
Dear all,

I've successfully embedded the Python interpreter into a set of C/C++
application programs that use a larger library project with information
from http://docs.python.org/api/api.html and
http://docs.python.org/ext/ext.html. Now I want to wrap classes and
functions from the associated libraries so that I can write new
applications completely in Python, but I'm not entirely sure how to
start because I have some problems understanding which is the best way.
It would be nice if someone could answer the following questions and
clarify this matter:

- until now I've used the approach as documented in
http://docs.python.org/ext/extending...embedding.html to extend the
embedded interpreter and that works pretty well. I'd like to use a
similar approach for other C applications. Can I write a C library that
implements this technique and link it into all C applications that need
Python support, or is there a better, more elegant way?

- in the documentation, there's an example that illustrates the creation
of a python module for pure extending of a python script (the Noddy
stuff). Do I have to make a separate module for each library I want to
wrap? If yes, how can I manage the case where two libraries can access
each other?

- if I write an extension module, how can I handle the case where the C
wrapper methods want to call back into the same Python interpreter instance?

- I think my questions break down into a reference to documentation
where a similar problem is explained in detail. Does anyone have such
information?

Thanks!
Thomas.
Jun 27 '08 #1
Share this Question
Share on Google+
1 Reply


P: n/a
En Tue, 20 May 2008 06:35:23 -0300, Thomas Troeger
<th****************@siemens.comescribió:
I've successfully embedded the Python interpreter into a set of C/C++
application programs that use a larger library project with information
from http://docs.python.org/api/api.html and
http://docs.python.org/ext/ext.html. Now I want to wrap classes and
functions from the associated libraries so that I can write new
applications completely in Python, but I'm not entirely sure how to
start because I have some problems understanding which is the best way.
It would be nice if someone could answer the following questions and
clarify this matter:

- until now I've used the approach as documented in
http://docs.python.org/ext/extending...embedding.html to extend the
embedded interpreter and that works pretty well. I'd like to use a
similar approach for other C applications. Can I write a C library that
implements this technique and link it into all C applications that need
Python support, or is there a better, more elegant way?
(I don't get what you mean by "this technique" and how would you write a
library)
- in the documentation, there's an example that illustrates the creation
of a python module for pure extending of a python script (the Noddy
stuff). Do I have to make a separate module for each library I want to
wrap? If yes, how can I manage the case where two libraries can access
each other?
Normally, yes, you'd write a wrapping module for each library. If both
access each other - well, you'd manage it the same way as you would do it
in C; you're just providing an interfase for calling the functions from
Python. (Hmm, maybe I have an "imagination crisis" today?)
- if I write an extension module, how can I handle the case where the C
wrapper methods want to call back into the same Python interpreter
instance?
I think there is no problem - unless your program is multithreaded, then
you should not release the GIL when calling into your extension if there
is a chance the C code may call Python code.
--
Gabriel Genellina

Jun 27 '08 #2

This discussion thread is closed

Replies have been disabled for this discussion.