Mateusz Loskot, 11.05.2012 11:38:
On 10 May 2012 18:58, Stefan Behnel wrote:
Mateusz Loskot, 10.05.2012 18:58:
Long story short, I have a software system implemented in C/C++ which
provides public API. The API is not fixed, may change, so scripting
engines use provided means of reflection to inspect this API and
generate bindings on-fly.
I embedded Python in this system and now I'm using the mentioned
reflection mechanisms to discover API and generate Python extension
modules and types dynamically during run-time.
I simply use the reflection mechanisms provided to iterate over
definitions (structures, functions, constants, etc.) of the public API
and I compose Python extension types grouping methods, etc.
Interesting. So you're reflecting on a C/C++ API to dynamically export it
to Python space?
Yes, roughly, that's the idea.
Then I guess that your internal binding code is also
rather generic, right?
Let's describe it in simplified way:
There are intermediate Python extensions defined which bridge
communication between the C++ world and dynamically generated Python classes.
For instance, there is a car and car engine.
Now, there is 'base car engine' which defines common protocol for
possible behaviours.
The 'base car engine" is specified and known at compile time,
Next, there is variety of kinds of engines where each provide
subset of the well-specified behaviours. Polymorphism, indeed.
So, those specific engines are dynamically generated in run-time
and they communicate with car through the statically defined 'base car
engine' protocol.
Hmm, that sounds more like you'd want to use a common compile time
interface for them statically instead, but I guess I'm just underestimating
the requirements here.
It won't be able to call the application code
directly, for example, if it doesn't know the API at compile time.
Yes, so there are 'base' extension types defined statically.
Makes sense.
I can not use Cython, nor I can use tools like SWIG, Boost.Python.
The (C)Python is the only tool I can use.
Also interesting. I wonder who would notice with which tool you have
written your source code once it's compiled...
I guess nobody. It's just I had not known Cython before I started.
Now, I have most of my implementation ready.
Sure, fair enough. (Although you wouldn't be the first one who ends up
rewriting C code in Cython.)
I also wouldn't want to introduce new dependencies
and as long as Cython is not guaranteed to be 100% compatible
drop-in replacement for Python 3.2+, then I'm afraid I can't use it.
The FAQ does not confirm it is
http://wiki.cython.org/FAQ#IsCythonaPythonimplementation.3F
Ah, that's the misunderstanding then. It's not meant as a replacement of
CPython, only as a replacement for writing C/C++ code using CPython's
C-API. It generates C code that runs on top of CPython and thus integrates
natively with both C/C++ code and Python code. So, basically, you get the
best of both worlds (C and Python) without having to write the C part of it.
Stefan
Stefan Behnel